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Vast  amounts  of  evolving  data  are  created  in  the  design  of  hard 
real-time  software  systems.  This  data  must  be  managed  so  that  it  can 
be  stored  and  retrieved  according  to  the  needs  of  design  engineers.  In 
the  Computer  -  Aided  Prototyping  System  (CAPS),  a  Design  Database 
(DDB)  must  manage  the  storage  and  retrieval  of  the  entire  Prototype 
System  Description  Language  (PSDL)  program.  This  thesis  presents  a 
conceptual  design  and  initial  implementation  of  a  Design  Database 
(DDB)  for  the  Computer  -  Aided  Prototyping  System  (CAPS). 
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I.  INTRODUCTION 


A.  BACKGROUND 

The  development  of  hard  real-time  and  embedded  software  systems 

is  an  extremely  complex  and  expensive  process.  A  software 

development  methodology  which  will  reduce  the  development  costs, 

increase  the  productivity  rates,  and  reduce  the  maintenance  costs  of 

these  systems  is  long  overdue.  The  prevailing  ideas  of  today  are 

computer-aided  rapid  prototyping,  software  reusability,  and  the  use  of 

an  executable  high-level  specification  language.  The  goal  of  the 

Computer-Aided  Prototyping  System  (CAPS)  is  to  integrate  all  of  these 

ideas  and  more,  into  one  software  development  tool.  [Ref.  l:p.  66] 

In  1985,  the  United  States  Department  of  Defense  (DOD)  spent 

roughly  $11  billion  dollars  in  software  costs  and  is  estimated  to  spend 

$36  billion  in  1995  [Ref.  2:p.  43J.  The  majority  of  these  costs  are 

involved  in  the  development  and  maintenance  of  embedded  systems 

[Ref.  3:p.  13).  These  costs  certainly  inspire  one  to  think  of  software 

development  in  terms  of  a  crisis.  As  stated  by  Booch: 

The  symptoms  of  the  software  crisis  appear  in  the  form  of  software 
that  is  nonresponsive  to  user  needs,  unreliable,  excessively 
expensive,  untimely,  inflexible,  difficult  to  maintain,  and  not 
reusable  [Ref.  3:p.  2). 
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Thus,  a  software  development  tool  which  can  provide  a  20  percent 
improvement  in  software  productivity  will  save  the  DOD  and  the 
American  taxpayer  billions  of  dollars. 


1.  Hard  Real-Time  and  Embedded  Software  Systems 

The  development  of  hard  real-time  and  embedded  software 
systems  creates  additional  problems  in  the  software  development 
process.  As  pointed  out  by  Booch: 

i 

they  all  generally  share  a  set  of  common  characteristics,  namely: 

•  Large.  Thousands/millions  of  lines  of  code. 

•  Long-lived.  10  to  15  years. 

•  Continuous  Change.  Due  to  changing  requirements. 

•  Physical  constraints.  In  target  hardware  address  space/speed. 

•  High  reliability.  Also  fault-tolerant.  [Ref.  3:p.  13] 

Each  of  these  characteristics  makes  embedded  systems  difficult  to 

develop.  For  this  reason,  the  DOD  mandated  the  use  of  Ada  in  all 

embedded  computer  software  programs,  whether  new  programs  or  j 

upgrades  to  existing  ones  [Ref.  4:p.  33].  The  effects  of  this  decision  on 

software  development  costs  may  not  be  felt  immediately  ,  but  the  long 

term  savings  of  a  universal  programming  language  for  embedded 

systems  will  be  realized. 

A  hard  real-time  system  is  defined  as  a  software  or  firmware 
controlled  system  that  performs  all  its  process  functions  within  critical 
specified  time  constraints  [Ref.  5:p.  3]. 
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An  embedded  system,  on  the  other  hand,  is  one  that  is  part  of  a  larger 
system  (Ref.  3:p.  3].  However,  embedded  systems  usually  require  hard 
real-time  constraints.  A  real-time  system  is  more  difficult  to  develop 
than  a  non-real-time  system.  As  discussed  in  Ref.  5,  some  of  the 
difficulties  include: 

•  Handling  of  stringent  time  requirements  and  performance 
specifications. 

•  Interfacing  with  a  real-time  clock. 

•  Control  of  hardware  devices  such  as  communication  lines, 
terminals,  and  resources. 

•  Processing  of  messages  that  arrive  at  irregular  intervals,  with 
fluctuating  input  rates,  and  with  different  priorities. 

•  Control  of  fault  conditions  with  facilities  for  various  degrees  of 
recovery. 

•  Handling  of  queues  and  buffers  for  storage  of  messages  and  data 
items. 

•  Modeling  of  concurrent  conditions  into  a  proper  set  of  concurrent 
processes. 

•  Allocation  and  control  of  concurrent  processes  to  processors. 

•  Handling  of  communication  and  synchronization  between 
concurrent  processes. 

•  Protection  of  data  shared  between  concurrent  processes. 

•  Scheduling  and  dispatching  (including  priority  handling)  of 
concurrent  processes. 
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Due  to  these  demanding  requirements,  the  development  of  hard 
real-time  and  embedded  systems  is  an  expensive  and  time  consuming 
process.  A  development  methodology  which  can  reduce  the 
development  cost  and  time  of  this  process  will  be  of  great  benefit  to 
the  DOD. 

2.  The  Computer-Aided  Prototyping  System 

The  Computer-Aided  Prototyping  System  is  one  attempt  to 
improve  the  productivity  and  reliability  of  software  through  the  use  of 
computer-aided  rapid  prototyping  via  specification  and  reusable 
components  [Ref.  l:p.  66].  This  approach  to  rapid  prototyping  uses  a 
specification  language  called  Prototype  System  Development  Language 
(PSDL)  integrated  with  a  set  of  software  tools  [Ref.  l:p.  66].  Figure  1 
gives  a  graphical  representation  of  CAPS  [Ref.  6:p.  8].  The  major 
components  of  CAPS  are  a  user  interface  consisting  of  a  syntax 
directed  editor  and  graphical  editor,  a  design  management  system 
consisting  of  a  software  base  management  system  and  design 
database,  and  an  execution  support  system  consisting  of  a  translator, 
dynamic  scheduler,  and  debugger.  For  further  explanations  of  the 
above  systems  see  Refs.  6,  7,  8,  9,  10,  11,  and  12. 

3.  The  Design  Database 

Vast  amounts  of  evolving  data  are  created  in  the  design  of  hard 
real-time  software  systems.  Conventional  database  management 
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systems  (DBMS)  were  designed  for  business  applications  and  as  such 
are  insufficient  to  handle  the  needs  of  computer-aided  design  (CAD) 
applications.  The  data  must  be  managed  so  that  it  can  be  stored  and 
retrieved  according  to  the  needs  of  design  engineers.  In  CAPS,  the 
Design  Database  (DDB)  must  manage  the  storage  and  retrieval  of  the 
Prototype  System  Description  Language  (PSDL)  program.  The  DDB 
must  be  a  specialized  DBMS  which  will  store  PSDL  specifications  in  a 
hierarchical  format. 
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Figure  1.  Computer-Aided  Prototyping  System 


4.  The  Object-Oriented  Approach 

As  stated  by  Ketabchi: 

There  is  an  increasing  interest  in  developing  object-oriented 
database  management  systems  to  manage  the  large  amount  of  data 
involved  in  computer-aided  design  (CAD)  applications  [Ref.  13:p.44J. 

In  the  past  three  years,  several  object-oriented  database  management 

systems  have  emerged.  The  impact  of  these  systems  on  the  software 

development  process  are  just  beginning  to  be  felt.  The  object-oriented 

approach  represents  a  true  paradigm  shift  [Ref.  14:p.  386]. 

B.  OBJECTIVES 

The  objective  of  this  thesis  is  the  development  of  a  conceptual  level 
design  and  initial  implementation  for  the  Design  Database  of  the 
Computer-Aided  Prototyping  System.  This  design  will  be  the  basis  for 
further  research  leading  to  full  implementation  of  the  Design  Database. 

C.  ORGANIZATION 

Chapter  II  contains  a  survey  of  recent  work  in  the  area  of  software 
engineering  databases  with  an  emphasis  on  the  object-oriented 
approach.  An  introduction  to  Vbase,  a  state  of  the  art  object-oriented 
DBMS  will  conclude  Chapter  II.  Chapter  III  contains  the  actual  design 
of  the  Design  Database.  Chapter  IV  shows  the  feasibility  of  the  Design 
Database  using  Vbase.  Conclusions  and  recommendations  will  be 
presented  in  Chapter  V. 


t 


6 


n.  ENGINEERING  DATABASES  AND  THE  OBJECT-ORIENTED 

APPROACH 

A.  ENGINEERING  DATABASES 

There  have  been  various  attempts  at  achieving  a  solution  to  the 
management  of  design  databases.  According  to  Berzins  and  Ketabchi: 
Four  different  approaches  to  the  solution  exist: 

(1)  Developing  a  new  DBMS,  called  a  design  DBMS  (DDBMS), 
equipped  with  facilities  required  in  design  applications. 

(2)  Enhancing  the  current  DBMSs  by  adding  new  capabilities. 

(3)  Building  a  layer  of  software  on  top  of  current  DBMSs  to 
compensate  for  their  deficiencies. 

(4)  Using  a  special-purpose  file  manager  that  views  the  DBMS  as 
an  application.  IRef.  15:p.  94J 

Sherpa  Data  Management  System  provides  an  example  of  the  first 
approach  IRef.  16:p.  55].  Starburst,  Almaden,  and  Postgres  provide 
examples  of  the  second  approach  [Ref  16:p.  571.  The  third  approach  is 
the  most  popular  approach  in  the  industry,  because  it  allows  the  use 
of  off-the-shelf  DBMS  and  can  be  made  rapidly  operational 
[Ref.  15:p.  94].  With  the  invention  of  object-oriented  technology,  the 
first  approach  will  become  the  most  popular  because  it  also  allows  the 
use  of  off-the-shelf  DBMS  but  with  enhanced  capabilities. 
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B.  THE  OBJECT-ORIENTED  APPROACH 

An  object-oriented  database  management  system  (OODBMS)  must 
provide  persistence,  concurrency,  recovery,  transaction  management, 
authorization,  and  security  (Ref.  16:p.  60J.  An  OODBMS  is  an 
object-oriented  system  and  as  such  it  must  also  provide  the  following 
capabilities: 

•  Objects 

•  Active  data 

•  Abstraction 

•  Extensibility  [Ref.  16:p.  61] 

An  OODBMS  should  provide  application-oriented  capabilities  such 
as: 

•  Version  and  configuration  control  for  CAD  applications. 

•  Dynamic  creation  of  classes. 

•  Recursive  classes,  multiple  inheritance,  and  extensive  tool 
interface  capabilities. 

•  Support  for  multimedia  objects,  distributed  environments,  and 
graphics.  [Ref.  16:p.  62] 

An  object-oriented  DBMS  is  one  that  supports  persistency,  values,  an 
extensible  set  of  data  structures,  an  extensible  set  of  operations,  and 
abstractions  [Ref.  16:p.  76]. 
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C.  VBASE 


The  Vbase  object-oriented  database  management  system  Is  a 
product  of  Ontologic,  Inc.  As  Ontologlc  puts  it: 

Vbase  is  an  object  database  system,  providing  an  Integrated 

software  development  platform  which  combines  the  latest  advances 

in  compiler  design  and  database  management  techniques 

[Ref.  17:p.  1]. 

The  Vbase  Integrated  Object  System  Is  a  database  and 
language  platform  for  rapidly  and  Inexpensively  building 
sophisticated  commercial  and  engineering  applications 
[Ref.  17:p.  51. 

The  Vbase  system  environment  consists  of  the  following 
components: 

•  Vbase  Database.  Persistent  objects  are  stored  in  the  Vbase 
Database. 

•  Object  Language.  Type  Definition  Language  (TDL)  is  the  Vbase 
data  definition  language.  It  is  used  to  define  object  types  in  the 
database.  "C"  Object  Processor  (COP)  is  the  Vbase  data 
manipulation  language.  It  is  an  object  extension  of  Kemlghan  and 
Ritchie  standard  C.  It  is  used  to  implement  the  operations  of  the 
object  types  defined  using  TDL. 

•  System  Type  Library.  The  system  type  library  contains  many 
object  types  which  provide  powerful  building  blocks  for  the 
application  developer. 

•  Integrated  Tool  Set  (ITS).  A  single  tool  combining  the  functionality 
of  a  source  browser,  database  browser,  and  a  source  debugger. 

•  Object  SQL.  The  Vbase  implementation  of  the  SQL  standard  query 
language.  [Ref.  17:p.  6] 

Figure  2  presents  a  graphical  representation  of  Vbase. 
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The  steps  involved  in  a  typical  Vbase  database  design  are  listed 
below: 

•  Identify  the  objects. 

•  Identify  their  properties  as  much  as  possible. 

•  Identify  the  frequent  operations  performed  on  the  objects. 

•  Define  the  objects  using  TDL. 

•  Compile  and  debug  the  TDL  definition  of  the  objects. 

•  Develop  COP  routines  to  implement  the  operations. 

•  Compile  and  debug  the  COP  programs. 

•  Develop  C  or  COP  user  applications.  IRef.  16:p.  8] 

Vbase  is  a  powerful  tool  for  implementing  and  maintaining  large 
software  applications.  Its  integration  of  compiler  technology  with 
database  functionality  in  a  strongly-typed  system  provides  both 
sophisticated  modeling  and  efficient  language  and  database 
performance. 
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Figure  2.  Vbase  Overview 
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in.  CONCEPTUAL  DESIGN  FOR  THE  DESIGN  DATABASE 


A.  REQUIREMENTS  FOR  THE  DESIGN  DATABASE  IN  RAPID 
PROTOTYPING 

The  purpose  of  the  Design  Database  (DDB)  in  the  Computer-Aided 
Prototyping  System  (CAPS)  is  to  manage  the  project  database  so  that  it 
can  be  stored  and  retrieved  according  to  the  needs  of  design  engineers. 
The  requirements  analysis  was  conducted  using  the  specification 
language  SPEC  [Ref.  18[.  SPEC  is  a  language  for  giving  black-box 
specifications  in  the  early  stages  of  software  design  [Ref.  18:p.  1J. 

As  stated  by  Berzins: 

The  goal  of  requirements  analysis  is  to  establish  the  purpose  of  the 

proposed  software  system  and  to  establish  constraints  and 

boundary  conditions  on  the  rest  of  the  software  development 

process  [Ref.  19:p.  1-2). 

The  result  of  the  requirements  analysis  should  include  the 
following: 

•  A  model  of  the  system’s  environment. 

•  A  description  of  the  goals  of  the  system  and  the  functions  it  must 
perform. 

•  Performance  constraints  on  the  system. 

•  Constraints  on  the  implementation  of  the  system. 

•  Resource  constraints  for  the  development  project. 

•  A  specification  of  the  external  interfaces  of  the  system. 

[Ref.  19:p.  2-1J 
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1.  Environment  Model 

As  stated  by  Berzins: 

The  environment  model  must  supply  the  concepts  needed  for 
describing  the  world  in  which  the  proposed  system  will  operate. 
These  concepts  consist  of  the  types  of  objects  in  that  world,  the 
attributes  of  those  objects,  the  relations  between  those  objects,  and 
the  laws  governing  those  objects  and  relations.  [Ref.  19:p.  2-2] 

The  environment  model  for  the  Design  Database  is  shown 
below.  The  model  was  formulated  in  terms  of  reusable  model 
components.  A  reusable  component  is  a  definition  of  a  general  type  or 
relation  [Ref.  19:p.  2-8].  The  reusable  components  used  are  shown  in 
Appendix  A  [Ref.  19:p.  2-9].  The  model  is  expressed  in  a  simple 
notation  that  is  explained  as  it  appears.  Explanatory  comments  are 
preceded  by  a  "  symbol.  A  grammar  for  the  notation  is  given  in 
Appendix  B  [Ref.  19:p.  2-21]. 
type  CAPS 

a„kind_ofisoftware_system  .CAPS) 

—  The  Computer-Aided  Prototyping  System  (CAPS)  is  a 
--  software_system. 

type  psdl 

a_kind_of[psdl,language) 

—  PSDL  is  a  language  for  expressing  specifications. 

created_by(every  psdl, a  user_interface) 

—  All  specifications  are  created  in  the  user  interface. 
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type  design_database 

a_kind_offdesign_database,software_system) 

—  The  design_database  is  going  to  be  a  software_system. 
part_ofIa  design_database, every  CAPS) 

—  The  design_database  is  part  of  CAPS 
unique(design_database) 

—  There  will  be  only  one  instance  of  the  design_database  for  each 

—  project. 

proposed(a  design_database) 

—  I  am  going  to  build  a  design_database. 
controls(a  design_database,node) 

—  The  design_database  controls  the  design  data  by 

—  managing  collections  of  data  called  nodes. 

type  design_engineer 

a_kind_ofldesign_engineer,user) 

—  The  design  engineer  is  a  user  of  the  system. 
uses(every  design_engineer,a  userjnterface) 

—  The  model  includes  only  the  design  engineers  that  will  interact 

—  with  the  design_database  via  the  user_interface. 
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type  user_interface 

a_klnd_of[user_interface,  software_system) 

--  The  user_interface  is  a  software_system. 
part_of(a  user_interface, every  CAPS) 

—  The  user_interface  is  a  part  of  CAPS. 
created_by(a  user_interface, every  node) 

—  The  userjnterface  is  the  only  source  for  data, 
type  data 

—  any  kind  of  data  that  is  used  by  a  software  system 
uses(a  software_system ,  every  data) 
relation  reads(software_system,  data) 

--  true  if  the  data  is  an  input  for  the  software  system 
reads(any  software_system,  any  data)  =>  uses  (software_system .data) 
relation  writes(software_system,  data) 

—  true  if  the  data  is  an  output  for  the  software  system 
writes(any  software_system,  any  data)  =>  uses  (software_system,data) 
relation  updates  (software.system,  data) 

—  true  if  the  data  is  both  an  input  and  an  output  for  the  system 
updates(any  software_system,  any  data) 

<=>  reads(software_system,  data)  &  writes(software_system,  data) 


type  node 

a_kind_of(node,data) 

--  A  node  is  the  basic  structure  for  maintaining  the  design  database. 
needed_for(node, every  specification) 

—  Every  specification  created  in  the  system  will  be  stored  in  a  node. 
created_by(every  node, a  user_interface) 

—  All  nodes  are  created  via  the  user  interface. 

—  The  attributes  of  a  node  are  listed  below. 
specification(node) :  psdl 
implementation(node) :  psdl 
control_constraints(node) :  psdl 
graphic_record(node):graphic_record 

—  A  node  consists  of  a  specification,  a  graphic  record, 

—  an  implementation,  and  control  constraints. 

text(node) :  psdl_file 
type  graphic_record 
a_kind_of(graphic_record  .data) 
part_of(node  ,graphic_record) 

—  A  graphic  record  is  one  input  into  in  a  node. 
created_by(a  userjnterface, every  graphic_record) 
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type  implementation 

a_kind_of(implementation ,  data) 
part_of!node ,  implementation) 

—  An  Implementation  is  one  input  into  a  node. 
created_by(a  user_interface,every  implementation) 

type  control_constraints 
a_kind_of(control_constraints ,  data) 
part_ofl(node,control_constraints) 

--  Control  constraints  are  part  of  the  data  in  a  node. 
created_by(a  user_interface, every  control_constraints) 
type  psdl_file 
a_kind_ofl[psdl_flle,  data) 

—  A  file  containing  the  PSDL  program  will  be  the  ultimate  output. 

2.  High  Level  Goals 

The  requirements  for  the  DDB  are  formalized  by  writing  a 
description  of  the  goals  of  the  system  and  the  functions  It  must 
perform  in  terms  of  the  model.  A  major  part  of  the  requirements 
analysis  is  turning  the  informal  problem  statement  into  a  precise, 
testable,  and  feasible  set  of  requirements.  The  high  level  goals  for  the 
Design  Database  are  shown  below. 
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Gl:  The  purpose  of  the  system  is  to  store  the  levels  of  a  PSDL 
design  in  a  hierarchical  format. 

Gl.l:  The  system  must  allow  design  engineers  to  retrieve  the 
levels  for  review  or  editing. 

G1.2:  The  system  must  be  able  to  create  and  insert  new  levels 
into  the  structure. 

Gl.2.1:  The  system  must  interface  with  the  user  interface  for 
inputs  to  the  database. 

G2:  The  system  must  be  able  to  generate  the  entire  PSDL 

program. 

3.  Constraints 

There  are  three  types  of  constraints  for  a  software  system: 
Implementation,  performance,  and  resource.  The  constraints  for  the 
Design  Database  are  given  below. 

Implementation  constraints: 

Cl:  The  design  database  must  be  implemented  with  a  DBMS  which  is 
compatible  with  the  Sun  workstation  and  Unix  operating  system. 

Performance  constraints: 

C2:  The  responses  of  the  design  database  must  be  fast  enough  not  to 
irritate  the  design  engineers  using  the  system. 
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Resource  constraints: 

C3:  The  Design  Database  will  be  developed  by  thesis  students  at  the 
Naval  Postgraduate  School. 

B.  CONCEPTUAL  MODEL  OF  THE  DESIGN  DATABASE 

The  DDB  is  a  hierarchical  storage  structure  for  the  PSDL  program. 
This  structure  is  a  tree  consisting  of  atomic  and  composite  nodes. 
Figure  3  illustrates  this  structure.  Both  types  of  nodes  contain  a  node 
name,  a  PSDL  specification,  an  implementation,  and  parent  <->  child 
relationship  information.  An  atomic  node’s  implementation  is  ADA 
code.  A  composite  node’s  implementation  is  graph.  A  graphic 
implementation  may  contain  timing  constraints  in  the  form  of  control 
constraints.  Each  level  of  the  tree  is  created  by  the  decomposition  of 
the  parent  node.  The  decomposition  process  is  complete  when  all  leaf 
nodes  are  atomic.  Figures  4  and  5  present  graphical  representations 
of  atomic  and  composite  nodes. 
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Figure  3.  Conceptual  DDB  Structure 
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NAME 

SPECIFICATION 

IMPLEMENTATION 
(ADA  CODE) 

PARENT  <->  CHILD  INFO 
Figure  4.  Atomic  Node 

NAME 

SPECIFICATION 

IMPLEMENTATION 

(GRAPH) 

CONTROL  CONSTRAINTS 
GRAPHIC  RECORD 

PARENT  <->  CHILD  INFO 
Figure  5.  Composite  Node 
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C.  FUNCTIONAL  SPECIFICATIONS  FOR  THE  DESIGN  DATABASE 


As  described  by  Berzins: 

A  functional  specification  is  a  precise  black-box  model  of  the 
proposed  software  system.  The  result  of  the  functional  specification 
phase  is  an  event  model  of  the  system  to  be  built,  expressed  in  a 
Spec  language.  In  the  event  model,  computations  are  described  in 
terms  of  modules,  events,  and  messages.  A  module  is  a  black  box 
that  interacts  with  other  modules  only  by  sending  and  receiving 
messages.  An  event  occurs  when  a  message  is  received  by  a 
module  at  a  particular  instant  of  time.  A  message  is  a  data  packet 
that  is  sent  from  one  module  to  another.  [Ref.  18:p.  2] 

A  further  description  of  the  Spec  language  by  Berzins  states: 

The  Spec  language  provides  a  means  for  specifying  the  behavior  of 
three  different  types  of  modules:  functions,  state  machines,  and 
abstract  data  types.  Function  modules  are  immutable,  and 
calculate  functions  on  data  types.  A  machine  is  a  module  with  an 
internal  state.  An  abstract  data  type  consists  of  a  set  of  Instances 
and  a  set  of  primitive  operations  involving  instances.  [Ref.  18:p.  3[ 

The  functional  specifications  begin  with  a  skeleton  of  a 
specification  with  places  for  each  of  the  missing  details  to  be  filled  in 
later.  The  initial  specifications  are  shown  below. 

MACHINE  design_database 

--  The  design  database  is  a  machine  because  it  is  time  sensitive. 

INHERIT  user_interface_interface 

--  The  system  will  interface  with  the  user  interface  portion  of  the 

—  CAPS  system  therefore,  inheritance  relations  exist. 

STATE 

INVARIANT  true 

INITIALLY  true 
END 
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MACHINE  user_interface 

—  The  userjnterface  is  an  external  system  that  sends  messages  to 

—  the  design  database. 

STATE 

INVARIANT  true 
INITIALLY  true 
END 

The  next  step  is  to  make  a  list  of  the  messages  in  each  interface 
by  consulting  the  requirements.  The  user  interface  is  the  only 
interface  for  the  design  database.  The  following  messages  are 

produced  corresponding  to  the  goals  of  the  system: 
user_interface_interface 
.  create_root_node  Gl,  G1.2 

create_child_node  Gl,  G1.2 

delete_node  Gl,  G1.2 

lookup_node  G 1 . 1 

get_parent  Gl.l 

get_child  Gl.l 

traverse_tree  G2 

These  messages  have  covered  all  of  the  goals  in  the  goal  tree  with  the 
exception  of  G  1.2.1.  This  goal  is  an  assumption  about  the 
environment. 
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The  result  of  the  user_interface  interface  messages  are  shown  below. 

MACHINE  user_interface_interface 

—  The  skeleton  specification  begins  by  identifying  the  interface 

—  messages. 

STATE  (tree:map{node,set{node}}) 

INVARIANT  existlng_nodes(node) 

INITIALLY  node  =  {} 

MESSAGE  lookup(node_name)  —  Gl.l 

—  Find  the  node  requested. 

WHEN  ?  —  node  found 

REPLY  node  —  return  node  contents 
OTHERWISE  REPLY  EXCEPTION  node  does  not  exist 

MESSAGE  getjiarent(node)  —  Gl.l 

—  Find  the  parent  of  the  node  requested. 

WHEN  ?  —  parent  found 

REPLY  node  —  return  parent  node 
OTHERWISE  REPLY  EXCEPTION  node  is  the  root 
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MESSAGE  get_child(node)  -  Gl.l 
—  Find  the  child  or  children  of  the  node  requested. 

REPLY  setjnode)  --  return  child  node(s) 

MESSAGE  create_root_node(node)  —  Gl.l,  G1.2 

—  Create  a  new  node  and  insert  into  the  top  of  the  hierarchy 
WHEN?  --  node  created 

REPLY  done 

TRANSITION?  -  add  root 

MESSAGE  create  child_node(node)  —  Gl.l,  G1.2 

—  Create  a  new  node  and  insert  into  the  hierarchy  correctly 
REPLY  done 

TRANSITION?  -  add  node 

MESSAGE  delete_node(node)  —  Gl.l,  G1.2 

—  Find  the  node  and  delete  it  and  all  children  from  the  structure. 
WHEN?  —  node  found 

REPLY  done 

TRANSITION?  —  remove  node  and  children 
OTHERWISE  REPLY  EXCEPTION  node  does  not  exist 
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MESSAGE  traverse_tree(node)  —  G2 

—  Find  the  requested  root  node  and  display  all  children  if  they  all 

—  consist  of  PSDL  specifications. 

WHEN?  —  node  found 

REPLY  setlnode} 

OTHERWISE  REPLY  EXCEPTION  psdl  program  does  not  exist 
END 


The  goal  of  functional  specification  is  to  construct  a  model  of  the 
proposed  system  as  it  is  visible  to  the  users  [Ref.  19:p.  1-31.  The 
concepts  that  the  users  will  be  expected  to  know  and  the  details  of  the 
interfaces  are  defined.  The  functional  specification  does  not  include 
any  information  on  how  the  system  behavior  is  to  be  realized.  The 
result  is  a  set  of  definitions  for  the  system  concepts  and  interfaces. 
The  major  functions  of  the  DDB  are: 

•  Store  the  levels  of  a  PSDL  program  in  a  hierarchical  format  by 
specification. 

•  Retrieve  the  levels  of  a  PSDL  program  in  a  hierarchical  format  by 
specification  for  review  or  editing. 

•  Create  and  insert  new  levels  of  a  PSDL  program  in  a  hierarchical 
format  by  specification. 

•  Generate  the  entire  PSDL  program. 
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A  brief  example  to  illustrate  the  expected  patterns  of  use  of  the 
methods  provided  by  the  DDB  follows.  To  construct  a  prototype,  the 
PSDL  specification  of  the  root  operator  is  entered.  At  this  point,  the 
DDB  would  create  a  root  node.  Assuming  the  root  node  is  composite, 
the  node  would  be  decomposed  into  children  operators.  The  DDB 
would  create  child  nodes  for  each  decomposition.  The  decomposition 
process  would  continue  until  all  leaf  nodes  are  atomic.  This  process 
will  be  time  consuming  and  the  prototype  will  be  complex.  For  this 
reason,  the  functions  of  retrieving  nodes,  parent-child  relationships, 
and  deleting  nodes  will  be  required.  The  tree  will  be  traversed  and  the 
entire  PSDL  program  produced  once  all  leaf  nodes  are  atomic. 

D.  ARCHITECTURAL  DESIGN 

The  next  step  in  the  design  process  is  to  develop  an  architectural 
design. 

An  architectural  design  is  a  model  of  the  proposed  system 
capturing  the  aspects  of  its  behavior  and  structure  relevant  to  the 
development  team.  The  behavior  of  a  system  consists  of  its 
interactions  with  other  systems,  while  the  structure  of  a  system 
consists  of  its  component  parts  and  their  interconnections. 

[Ref.  19:p.  4-53] 

The  functional  specification  is  a  subset  of  the  architectural  design. 
The  functional  specification  is  the  least  detailed  view  of  the  system. 
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'The  goal  of  the  architectural  design  is  to  break  up  the  proposed 

system  into  a  set  of  small  modules."  [Ref.  19:p.  4-54J  A  module  is 

defined  as  a  self  contained  unit  of  code. 

A  module  is  both  a  self-contained  abstraction  and  a  unit  of  work. 
Modules  have  several  different  views:  black-box  specification,  parts 
lists,  glass-box  specifications,  and  programs.  [Ref.  19:p.  4-54] 

Black-box  specifications  are  expressed  in  terms  of  the  event  model  at 
the  architectural  design  and  functional  specification  stage.  The  parts 
lists  contains  the  set  of  lower  level  modules  used  directly  in  the 
implementation.  Glass-box  specifications  are  represented  by  pseudo¬ 
code.  Programs  are  produced  in  the  implementation  phase. 

[Ref.  19:p.  4-54]  The  black-box  specifications  will  be  shown  below. 
The  parts  lists  and  pseudo-code  are  not  contained.  Programs  will  be 
discussed  in  Chapter  IV. 

Black-box  specifications 
Type  Node 

Model  (specification  implementation  graphic_record 
control_constraints:  string) 

--  The  following  messages  are  used  to  replace  the  current  value  of 
--  a  node’s  property  with  a  new  value. 

MESSAGE  add_graphic_record(node) 

TRANSITION?  —  update  node  graphic  record  info 
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MESSAGE  add_implementation(node) 

TRANSITION?  --  update  node  Implementation  info 

MESSAGE  add_specification(node) 

TRANSITION?  —  update  specification  info 

MESSAGE  add_controI_constraints(node) 

TRANSITION?  --  update  control  constraints 
END 


The  result  is  a  lower  level  set  of  definitions  for  the  system  concepts 
and  interfaces.  These  messages  reveal  operations  on  the  abstract  data 
type  node.  The  lower  level  messages  in  the  userjnterface  interface 
are: 

add_graphic_record 

addjmplementation 

add_specification 

add_control_constraints 

The  addition  of  these  messages  creates  an  additional  function 
requirement: 

•  Create  and  maintain  version  control. 
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A  new  node  could  be  created  when  a  nodes’  properties  are  significantly 
changed  by  these  low  level  messages.  The  ability  ro  define  a 
significant  change  will  be  required.  The  current  Implementation  of  the 
DDB  does  not  address  this  function.  Chapter  IV  does  contain  a 
discussion  of  version  control. 

As  evidenced  by  the  functions  required  of  the  DDB,  a  conventional 
DBMS  will  not  suffice.  Therefore,  an  object-oriented  DBMS  will  be 
used  to  design  and  implement  the  DDB.  The  object-oriented  DBMS 
that  will  be  used  is  Vbase  by  Ontologic  Incorporation. 
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IV.  FEASIBILITY  FOR  THE  DESIGN  DATABASE  USING  VBASE 

A.  EXAMPLES  OF  COMPONENTS  IN  THE  DESIGN  DATABASE 
1.  Type  Definition 

As  stated  earlier,  the  first  steps  in  a  Vbase  design  are  to 

identify  the  objects,  their  properties,  and  the  frequent  operations 

performed  on  the  objects.  The  next  step  is  to  define  the  objects  in 

TDL.  The  only  object  in  the  Design  Database  is  a  Node.  The 

properties  of  a  node  were  defined  earlier  as  well.  The  frequent 

operations  are  those  necessary  to  assist  in  the  accomplishment  of  the 

required  functions  of  the  design  database.  The  TDL  code  below 

illustrates  the  definition  of  a  Node. 

define  Type  Node 

supertypes  =  {Entity} 

properties  =  { 

name:  String; 
specification:  String; 
implementation:  optional  String; 
controlconstraints:  optional  String; 
graphicrecord:  optional  String; 

subNodes:  distributed  SetfNode]  inverse  $Node$isChildOf; 
isChildOf:  optional  Node  inverse  $Node$subNodes; 

I 

The  main  points  to  notice  about  the  above  definition  are  the 
supertypes,  optional,  and  inverse  keywords.  The  supertypes 
declaration  is  used  to  show  the  parent  class  of  a  type.  This  is  used 
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for  inheritance  purposes.  The  supertype  Entity  is  the  root  of  all  types 
in  the  Vbase  system  type  library  {Ref.  17:p.  IX-6].  Entity  specifies 
basic  behavior  for  all  object  types  in  the  system. 

The  keyword  optional  specifies  that  a  property  need  not 
necessarily  have  a  value.  This  indicates  that  a  PSDL  specification  may 
or  may  not  have  an  implementation,  control  constraints,  or  graphic 
record.  The  implementation  property  is  optional  due  to  the  process 
through  which  PSDL  specifications  are  created.  The  control 
constraints  and  graphic  record  are  true  optional  properties  in  that  they 
may  or  may  not  ever  exist  depending  on  whether  implementation  is 
graphic  or  ADA. 

The  inverse  property  sets  up  a  system-maintained  relationship 
between  the  property  defined  and  its  specified  inverse.  This  property 
is  used  to  maintain  the  parent-child  relationship  between  Nodes.  The 
inverse  property  also  illustrates  the  "$"  notation.  The  "$"  notation  is 
used  to  provide  a  mechanism  for  referring  to  names  relative  to  their 
scope.  The  symbol  "$"  acts  as  a  pathname  separator. 

The  next  step  is  to  define  the  frequent  operations  on  the  object. 
The  clause  "operations  =  {...};"  defines  the  set  of  operations  that  type 
Node  will  implement.  The  operations  for  a  Node  are  buildDisplay, 
listsubNodes,  listsubNodesIntemal,  and  a  refinement  of  the  delete 
operation.  BuildDisplay  is  used  for  output  of  a  Node  contents. 
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ListsubNodes  and  UstsubNodesIntemal  are  used  to  retrieve  the 
children  of  a  particular  Node.  The  refines  delete  operation  means  the 
current  definition  is  refining  an  operation  already  defined  in  the 
supertype.  The  actual  refinement  is  achieved  in  the  COP  method 
which  implements  the  operation  and  will  be  described  later.  The 
operations  for  a  Node  are  defined  as: 

operations  =  { 

buildDisplay  (n:Node.) 
returns(Node) 

method  (NodeBuildDisplay); 

listSubnodes  (n:Node) 
returns  (Set[Node]) 
method  (NodeListSubNodes); 

listSubnodesIntemal  (n:Node,  s:Set  [Node]) 
returns  (Set[Node] 
method  (NodeListSubNodeslnt); 

refines  delete  (n:Node) 
raises  (CannotDelete) 
triggers  (NodeDeleteTrigger); 


The  definition  of  a  Node  includes  two  procedure  definitions: 
define  Procedure  Create  ...  end  Create; 
and 

define  Procedure  Lookup  ...  end  Lookup; 

Procedures  differ  from  typed  operations  in  that  they  are  not  tied  to  a 
type.  For  example,  the  operation  $Node$buildDisplay  can  only  be 
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called  on  instances  of  type  Node,  while  the  procedure  $Node$Lookup 

can  be  called  with  any  arguments  which  satisfy  the  argument  type 

specification  of  the  procedure.  The  procedure  Create  has  an  argument 

specification  of  the  form: 

define  Procedure  Create 
(t:Type, 
keywords 
name:  String, 
specification:  String, 
optional  implementation:  String, 
optional  controlconstraints:  String, 
optional  graphicrecord:  String, 
optional  isChildOf:  Node, 
optional  where:  Entity, 
optional  hownear:  Clustering 

) 

returns  (Node) 
raises  (NodeAlreadyExists) 
triggers  (NodeCreateTrigger) 
supertypes  =  ($Entity$Create); 
end  Create; 

This  specification  gives  more  examples  of  the  power  of  Vbase. 
Specifically,  the  keywords  "keywords",  "raises",  "triggers",  and 
"hownear".  The  keyword  "keywords"  specifies  that  the  remaining 
arguments  are  passed  by  keywords,  rather  than  by  position  in  the 
argument  list. 

The  statement  "raises  (NodeAlreadyExists)"  specifies  that  the 
procedure  may  raise  the  exception  NodeAlreadyExists.  This  exception 
is  to  alert  the  caller  that  the  Node  already  exists,  rather  than  creating 
a  new  copy  of  the  Node. 
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The  Create  procedure  also  has  a  triggers  clause,  "triggers  = 
(NodeCreateTrigger)".  The  Vbase  system  automatically  generates  a 
Create  Procedure  for  every  type  defined.  An  explicit  definition  is 
required  to  specify  a  trigger  to  the  system-defined  Create.  A  trigger  is 
a  method  associated  with  the  invocation  of  a  procedure  or  operation. 
Whenever  the  Create  procedure  is  invoked,  the  trigger, 
NodeCreateTrigger,  will  be  executed  first.  The  trigger  checks  whether  a 
Node  already  exists  before  creating  a  new  one.  An  operation  can  have 
more  than  one  trigger  associated  with  it.  The  triggers  are  invoked  in 
the  order  they  are  listed,  and  the  last  trigger  must  invoke  the  base 
method.  The  base  method  is  the  method  which  is  specified  as 
implementing  the  operation  or  procedure.  [Ref.  17:p.  10-11] 

The  optional  keywords  where  and  hownear  can  be  used  in  the 
Create  operation  to  optimize  disk  storage  of  the  object  created  to 
improve  database  performance.  The  type  Clustering  is  an  enumerated 
type  with  three  instances:  $area,  $segment,  and  $chunk.  Each  is  a 
unit  of  storage  on  the  disk.  Segment  is  the  atomic  unit  of  transfer 
from  disk  to  the  main  memory  cache.  To  specify  that  an  object 
created  is  to  be  stored  in  the  same  segment  as  some  other  object,  the 
value  of  the  hownear  argument  is  "$segment"  and  the  value  of  the 
where  argument  is  the  other  object.  $Area  and  $chunk  are  not 
currently  supported.  [Ref.  17:p.  IX-41] 
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The  second  procedure  defined  is  called  Lookup.  This  procedure 

is  used  to  look  up  a  given  Node,  identified  by  its  Node  name,  in 

NodeCatalog  which  is  a  global  Node  catalog.  The  specification  for 

procedure  Lookup  is  as  follows: 

define  Procedure  Lookup  (s:String) 
returns  (Node) 
raises  (NodeNotlnCatalog) 
method  (NodeLookup) 
supertypes  =  (Entity); 
end  Lookup; 

There  is  one  additional  TDL  definition  in  the  DDB, 
NodesExceptions.tdl.  NodesExceptions  contains  the  definitions  of  the 
exceptions  used  in  the  application.  The  complete  TDL  definitions  are 
listed  in  Appendix  C. 

2.  COP  Definition 

The  next  step  in  the  design  of  a  Vbase  application  is  to 
implement  the  frequent  operations  using  COP.  COP  is  an  object-based 
superset  of  the  language  C.  This  can  be  either  an  advantage  or  a 
disadvantage  of  Vbase,  depending  on  the  designers  knowledge  of  the  C 
language.  One  method  implemented  for  the  object  Node  was 
"NodebuildDisplay".  This  operation  is  used  to  output  the  contents  of  a 
Node  to  a  file.  The  COP  code  below  implements  the  method: 
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#include  <stdio.h>  /*  include  standard  C  routines  */ 

#include  <string.h> 

fdefine  MAXLINE  81  /*  maximum  line  length  is  81  characters  */ 

fdefine  MAXSTRING  4000  /*  maximum  string  length  is  4000  */ 
char  opname[MAXLINE];  /*  declaration  of  local  variables  */ 

FILE  *out; 

char  spec  text  [MAX  STRING], 
imptext  [MAXSTRING] , 
cctext  [MAXSTRING]; 

import  $Type; 
import  $Class; 
enter  module  $Node; 

method 
obj  $Node 

NodeBuildDisplay(aNode) 
obj  $Node  aNode; 

{ 

out  =  fopen("ddb.out",  "a"); 

/*  convert  object  code  to  C  code  */ 

AM_stringToC(aNode  .name  .opname,  sizeof[opname)) ; 
fprintf(out,"%s\n",opname); 

AM_stringToC(aNode. specification,  spectext,  sizeofispectext)); 
fprintf  (out,"%s\n",  spectext); 

/*  determine  if  optional  property  has  a  value  */ 

/*  before  executing  an  operation  on  it.  V 

if  (hasvalue(aNode.implementation)) 

{ 

AM_stringToC(aNode. implementation,  imptext,  sizeofiimptext)); 
fprintfiout,  "%s\n",  imptext); 

} 

if  (hasvalue(aNode.controlconstraints)) 

{ 

AM_stringToC(aNode.controlconstraints,  cctext,  sizeoftcctext)); 
fprintflout,  ’’%s\n",  cctext); 

) 

fclose(out); 

retum(aNode); 

} 
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This  example  helps  to  show  the  ability  to  Interweave  the 
standard  C  language  with  COP.  Object  code  and  variables  are 
prefaced  by  the  "$"  symbol.  This  Is  used  to  distinguish  object 
variables  from  standard  C  variables. 

The  declarative  statements  "Import"  and  "enter  module"  are 
used  for  name  visibility.  Making  a  name  visible  provides  the  COP 
compiler  with  a  reference  to  what  the  name  defines.  Database  names 
are  defined  in  the  Vbase  Kernel  Database  and  In  TDL  code.  Names 
defined  in  the  Vbase  Kernel  Database  are  globally  defined  In  a  default 
set.  Names  not  included  In  the  default  set  must  be  made  visible 
explicitly  using  the  "import"  and  "enter  module"  statements.  An 
"import"  declaration  imports  the  definitions  of  a  set  of  database  names 
so  they  are  visible  within  the  current  COP  compilation  unit.  An  "enter 
module"  declaration  establishes  visibility  for  all  names  defined  in  a 
module.  [Ref.  17:p.  VII -3] 

The  functions  "hasvalue"  and  "AM_stringToC"  are  system 
supplied.  The  function  "hasvalue"  is  used  to  test  whether  an  optional 
property  has  a  value  before  executing  any  operations  on  it.  This  is 
necessary  because  of  the  strong-typing  of  Vbase.  The  function 
"AM_stringToC”  is  used  to  convert  from  an  object  string  to  a  standard 
C  string  for  use  by  systems  external  to  the  Vbase  database. 
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Two  other  operations  defined  where  "NodeListSubNodes"  and 
"NodeLlstSubNodesIntemal".  These  operations  are  used  to  assist  In 
the  traversal  of  the  tree  structure.  The  COP  code  to  Implement  these 
operations  is  shown  below: 

method 

obj  $Set[obj  $Node] 

NodeListSubNodes(aNode) 
obj  $Node  aNode; 

( 

obj  $Set[obj  $Node]  theSubNodes; 
theSubNodes  =  $Set[obj  $Node]$Q; 
$Node$ListSubNodesIntemal(aNode,  theSubNodes); 
retum(theSubNodes); 

} 

method 

obj  $Set[obj  $Node] 

NodeListSubNodesInt(aNode,  theSubNodes) 

obj  $Node  aNode; 

obj  $Set[obj  $Node]  theSubNodes; 

I 

obj  $Node  currentNode; 
iterate(currentNode  =  aNode.  SubNodes) 

{ 

$Set$Insert(theSubNodes ,  currentNode) ; 
$Node$ListSubNodesIntemal(currentNode,  theSubNodes); 

} 

retum(theSubNodes); 

1 

This  code  helps  to  demonstrate  other  powerful  capabilities  of  Vbase. 
One  is  the  ability  of  one  method  to  invoke  another  method.  This  is 
shown  in  the  method  "NodeListSubNodes".  The  other  capability* is  the 
system  supplied  iterator  operation.  This  operation  is  used  to  control 
aggregate  types.  The  system  defined  iterator  can  be  modified  to  return 
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the  aggregate  in  any  order  the  user  decides. 

The  remaining  operations  and  methods  are  listed  in  Appendix 
C.  The  above  was  shown  to  demonstrate  the  feasibility  and  power  of 
Vbase. 

3.  Application  Programs 

The  final  step  in  a  Vbase  design  is  to  develop  C  or  COP  user 
applications.  The  user  applications  developed  correspond  to  the 
functional  specifications  and  architectural  design.  The  user 
applications  developed  in  response  to  the  functional  specifications  are: 

•  CreateRootNode.  Used  to  create  a  Node  which  is  the  root  of  a  tree. 

•  CreateChildNode.  Used  to  create  a  Node  which  is  a  child  of  a 
Node. 

•  GetParent.  Used  to  retrieve  the  name  of  a  Node’s  parent  Node. 

•  GetChildren.  Used  to  retrieve  the  name(s)  of  a  Node’s  child 
Node(s). 

•  DeleteNode.  Used  to  delete  a  Node  and  it’s  children  from  the  tree. 

•  TraverseTree.  Used  to  traverse  the  entire  tree  structure  to  generate 
the  PSDL  program. 

The  user  applications  developed  in  response  to  the  architectural  design 
are: 

•  StoreProperty.  Used  to  update,  insert,  or  change  the  value  of  a 
Node’s  property. 

•  GetProperty.  Used  to  retrieve  the  contents  of  a  Node's  property. 
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The  applications  were  all  implemented  using  COP.  They  are 

shown  in  Appendix  D.  The  actual  code  for  some  of  these  applications 

is  quite  long,  therefore  the  code  for  TraverseTree  will  be  shown  here  for 

demonstration  purposes.  This  application  takes  as  input  the  name  of 

the  root  Node  of  a  tree.  It  then  iterates  through  the  entire  tree  writing 

the  properties  of  a  Node  to  the  output  file  "ddb.out". 

#include  <stdio.h>  /*  include  standard  C  routines  */ 

#include  <string.h> 

#deflne  LINELENGTH  80 

#de£Lne  MAXLINE  81  /*  maximum  linelength  is  81  characters  */ 
FILE  "in,  *out;  /*  local  variable  declarations  */ 
char  rootname[MAXLINE], 
tempnamelMAXLINE] ; 
import  $Node; 
main(argc,  argv) 
int  argc; 
char  **argv; 

I 

/*  local  object  variables  */ 
char  *  dbname; 
char  *getenv(); 

obj  $Node  theNode,  currentNode; 
obj  $Set[obj  $Node]  theNodes; 
obj  $String  theRoot; 
if  (argc  >  1) 

{ 

dbname  =  argv[l]; 

} 

else  if  (dbname  =  getenvf'DBNAME")) 

{ 

} 

else 

( 

printf("Must  specify  database  name,  either  as  a  command 
line  argument, \nor  via  the  Unix  environment  variable 
DBNAMEXn"); 
exit(l); 

) 
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{ 

AM_databaseOpen(dbname,  0); 
in  =  fopenC'ddb.in",  "r"); 
out  =  fopen("ddb.out",  "w"); 
fclose(out); 

fgets(tempname,  LINELENGTH,  in); 
strncpy(rootname,  temp  name,  (strlen(tempname)  -  1)); 
theRoot  =  rootname; 
theNode  =  $Node$Lookup(theRoot); 

(void)  $Node$BuildDisplay(theNode); 

theNodes  =  $Node$listSubnodes(theNode); 
iterate(currentNode  =  theNodes) 

{ 

(void)  $Node$BuildDisplay(currentNode); 

} 

) 

protect 

AMdatabaseClose(dbname); 


The  above  code  illustrates  two  additional  keywords:  "void"  and 
"protect".  "Void"  is  a  standard  C  keyword,  indicating  that  the  method 
does  not  return  a  value.  The  method  simply  outputs  the  information 
passed  to  it. 

"Protect"  ensures  execution  of  a  statement  when  an  exception  is 
raised.  "Protect  AM_databaseClose(dbname)"  ensures  the  database 
involved  is  closed  in  the  event  an  exception  is  raised. 

4.  Interface  Requirements  of  the  DDB  and  User  Interface 

The  current  implementation  of  the  DDB  is  invoked 
automatically  by  the  User  Interface.  The  design  engineer  is  not 
required  to  have  any  knowledge  of  the  DDB.  For  example,  whenever  a 
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designer  creates  a  new  root  Node,  the  User  Interface  will  automatically 
retain  the  needed  information  and  invoke  the  "createRootNode" 
application.  The  same  is  true  for  all  the  other  operations  of  the  DDB. 
An  excellent  followup  thesis  to  this  one  can  concentrate  on 
implementing  a  graphical  interface  between  the  two  systems  to  allow 
manual  and  automatic  operation  invocation.  The  goal  of  the  system 
should  be  to  make  the  underlying  system  transparent  to  the  user. 

Input  and  output  between  the  DDB  and  User  Interface  is 
accomplished  through  the  use  of  two  files  titled  "ddb.in"  and  "ddb.out". 
The  input  format  required  for  each  application  is  described  below  and 
is  maintained  by  the  User  Interface. 

(1)  Create  Root  Node  -  used  to  create  a  root  node. 

Format  required  for  ddb.in 

•  node  name 

•  specification 

•  implementation  (optional) 

•  control  constraints  (optional) 
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(2)  Create  Child  Node  -  used  to  create  a  child  node. 

Format  required  for  ddb.in 

•  node  name 

•  parent  node  name 

•  specification 

•  implementation  (optional) 

•  control  constraints  (optional) 

(3)  Store  Property  -  used  to  store  or  change  a  node  property. 
Format  required  for  ddb.in 

•  node  name 

•  property 

(4)  Get  Property  -  used  to  retrieve  a  node  property. 

Format  required  for  ddb.in 

•  node  name 

•  property  name 
output  to  ddb.out 

•  property 
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(5)  Get  Children  -  used  to  retrieve  the  names  of  a  parent  nodes 
children. 

Format  required  for  ddb.in 

•  parent  node  name 
output  to  ddb.out 

•  child  node(s)  names 

(6)  Get  Parent  -  used  to  retrieve  the  name  of  a  child  nodes  parent. 
Format  required  for  ddb.in 

•  child  node  name 

output  to  standard  output  device 

•  parent  node  name 

(7)  Delete  Node  -  used  to  delete  a  node  and  all  of  it’s  children. 
Format  required  for  ddb.in 

•  node  name  to  delete 

(8)  Traverse  Tree  -  used  to  traverse  the  entire  tree  and  produce  the 
psdl  program. 

Format  required  for  ddb.in 

•  root  node  name 
output  to  ddb.Out 

•  entire  psdl  program 
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5.  Version  Control 


The  version  control  function  has  not  been  addressed  to  date. 
The  previous  functions  were  implemented  without  concern  for  version 
control.  However,  the  issue  of  version  control  is  an  important  one  and 
must  be  addressed  in  future  implementations. 

A  pre-release  article  from  Ontologic,  Inc.  describes  a  history 
mechanism  embedded  into  the  Vbase  Object  Manager  [Ref.  20:p.  1). 
However,  this  feature  has  not  been  implemented  in  current  releases. 
A  discussion  of  the  key  points  raised  in  the  article  will  be  helpful  to 
further  explain  the  issue  of  version  control.  Hopefully,  future  Vbase 
releases  will  incorporate  this  feature. 

There  are  two  basic  approaches  to  version  control:  linear  and 
non-linear  evolution.  Linear  evolution  is  a  series  of  states  through 
which  an  entity  passes  as  it  is  mutated  [Ref.  20:p.  1].  A  version  is  a 
snapshot  of  the  entity  at  a  point  in  time.  The  whole  set  of  versions, 
called  its  Version-Set,  represents  the  entire  history  of  an  entity  [Ref. 
20: p.  2].  Figure  6  gives  a  graphical  representation  of  the  Version-Set. 

V:  (vl  — >v2  — >v3  — >v4} 

Figure  6.  Version  Set 

Non-linear  evolution  is  defined  as  a  situation  in  which  a  version 
has  more  than  one  successor  or  more  than  one  predecessor  version 
[Ref.  20:p.  5].  In  order  to  correctly  maintain  these  relationships,  there 
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must  be  a  method  to  describe  the  default  path  from  a  version.  The 
other  required  method  is  to  describe  alternatives  to  the  default  path. 
The  system  must  resolve  a  simple  reference  by  default  to  the  most 
recent  version  in  a  linear  evolution  path,  and  to  the  default  branch  of 
a  forking  evolution  path,  so  simple  references  are  unambiguous 
[Ref.  20:p.  5]. 

There  are  two  ways  to  make  a  new  version:  manually  or 
automatically.  Manual  version  creation  can  be  invoked  by  the  user 
whenever  he  thinks  that  a  significant  change  has  occurred.  Automatic 
version  creation  is  invoked  without  the  intervention  of  the  user 
[Ref.  20:p.  3].  This  is  controlled  by  the  type  of  the  entity  via  its 
property  and  operations  definitions. 

In  addition  to  the  PSDL  components  of  a  Node,  there  must  be 
audit  trail  information  stored  in  the  Node  for  version  control.  The 
current  implementation  of  the  DDB  does  not  include  audit  trail 
information.  The  recommended  audit  trail  information  to  be  used  in 
future  implementations  is  given  in  Figure  7. 

As  previously  stated,  a  system  supplied  version  mechanism  is 
not  implemented  in  current  release  versions.  The  set  of  tools  required 
to  implement  version  control  are  within  Vbase  and  could  be 
implemented  by  the  designer.  This  would  be  another  excellent 
followup  thesis  to  this  one. 
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PROJECT  NAME 


RESPONSIBLE  ENGINEER 


WHEN  CREATED 


WHEN  LAST  UPDATED 


VERSION  NUMBER 


CURRENT  VERSION 


Figure  7.  Audit  Trail  Properties 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  SUMMARY  AND  CONCLUSIONS 

The  development  of  hard,  real-time  software  systems  continues  to 
be  an  expensive  process  for  the  DOD.  The  Computer-Aided 
Prototyping  System  (CAPS)  is  one  tool  under  development  which  will 
help  to  decrease  the  costs  of  these  systems.  CAPS  is  an  attempt  to 
integrate  several  of  the  prevailing  software  development  methodologies 
into  one  tool.  With  a  central  theme  of  rapid  prototyping,  CAPS  shows 
great  promise  for  the  future  of  software  development  in  the  DOD. 

This  thesis  concentrated  on  the  development  of  the  Design 
Database  (DDB)  for  CAPS.  It  is  a  key  element  of  the  system  as  project 
management  has  become  an  issue  of  increasing  importance  in  software 
development.  A  robust  Design  Database  which  can  efficiently  and 
effectively,  store  and  retrieve  the  Prototype  System  Description 
Language  (PSDL)  program  will  significantly  contribute  to  the  overall 
success  of  CAPS. 

The  goal  of  this  thesis  has  been  to  develop  a  conceptual  level 
design  and  initial  implementation  of  the  Design  Database  for  CAPS. 
The  basic  design  was  developed  using  the  object-oriented  approach 
and  the  initial  implementation  was  accomplished  with  an  object- 
oriented  DBMS  (Vbase).  Object-oriented  technology  offers  several 
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enhancements  to  current  DBMS  technology,  and  with  its  maturity  it 
will  become  as  important  to  CAD  applications  as  relational  database 
technology  has  become  to  business  applications.  This  study  has 
accomplished  the  goals  of  the  thesis  and  identified  key  aspects  of  the 
design  Database  for  continued  implementation  and  follow-up  thesis 
work. 

B.  RECOMMENDATIONS  FOR  FURTHER  RESEARCH 

This  thesis  has  provided  a  foundation  for  further  implementation  of 
the  Design  Database.  Further  research  and  testing  is  required  to 
complete  full  implementation  of  the  system  and  to  identify  potential 
weaknesses.  This  author  recommends  work  in  the  following  specific 
areas: 

•  The  design  and  implementation  of  version  control  within  the  design 
database.  The  issue  of  version  control  is  an  important  one  and 
must  become  an  integral  part  of  the  DDB  if  it  is  to  become  an 
effective  part  of  CAPS. 

•  The  design  and  implementation  of  a  graphical  interface  between  the 
User  Interface  and  the  remainder  of  CAPS.  Without  an  effective 
User  Interface,  CAPS  will  find  little  usefulness  in  the  "real  world". 

•  The  study  of  memory  management  for  the  DDB  as  well  as  the 
entire  system.  Each  application  in  Vbase  requires  two  megabytes 
of  memory.  With  the  DDB  and  the  SBMS  both  implemented  in 
Vbase,  the  memory  requirements  for  these  two  systems  alone  will 
be  immense. 

•  The  design  and  implementation  of  an  efficient  method  for 
constraint  checking  within  the  various  levels  of  decomposition. 
Currently,  the  User  Interface  is  maintaining  minimal  information 
for  this  purpose  but  a  more  elaborate  system  is  required. 
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APPENDIX  A 


REUSABLE  COMPONENTS  LIBRARY 

The  model  was  formulated  in  terms  of  reusable  components  for 
business  applications.  The  reusable  component  library  used  is  shown 
below  as  taken  from  Ref.  19.  Explanatory  comments  extend  from  the 
leftmost  ' "  to  the  end  of  the  line. 

relation  is_a(object,type) 

—  Means  the  object  is  an  instance  of  the  type. 
is_a(every  object, a  type) 

—  Every  object  is  an  instance  of  some  type. 

relation  a_kind_of(type .type) 
a_kind_ofjany  type  1. any  type2)  <=> 

(is_a(any  object, type  1)  =>  is_a(object,type2)) 

--  a_kind_ofltype  1  .type 2)  means  typel  is  a  subset  of  type2. 

type  object 

a_kind_of)any  type.object) 

--  Any  type  is  a  subset  of  the  universal  type  "object", 
type  type 

—  The  set  of  all  types. 

is_a(an  object  1, any  object2)  <=>  is_a(object2 ,  type) 

—  Any  object  with  instances  is  a  type  and  all  types  are  non-empty. 

type  relation 

—  The  set  of  all  relations. 

~(is_a(any  object.type)  &  is_a(object, relation)) 

—  Types  and  relations  do  not  overlap. 

relation  unique(type) 

—  Means  there  is  only  one  instance  of  the  type, 
uniquefany  type)  <=> 

is_a(any  object  1, type)  &  is_a(any  obJect2,type)  ->  equal(objectl,object2) 
type  software_system 

--  The  set  of  systems  to  be  realized  as  programs. 

relation  proposed(software_system) 

--  Means  the  software  system  is  going  to  be  developed. 
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relation  eontrols(software_system,type) 

—  Means  the  instances  of  the  type  are  created,  modified,  and 

—  destroyed  only  by  means  of  the  software  system. 

type  agent 

—  The  cause  of  an  activity,  usually  a  person  or  organization, 
type  activity 

—  The  set  of  all  processes  and  actions, 
type  user 

a_kind_of(user ,  agent) 

—  A  class  of  users  of  a  software_system. 
usesfevery  user, a  software_system) 

relation  uses(user,software_system) 

—  Means  the  user  depends  on  the  software jsystem  to  achieve  some 

—  goals. 

relation  main  tains  (user,  type) 

—  Means  the  instances  of  the  type  are  created,  modified,  or 

—  destroyed  upon  request  from  the  user. 

maintains(any  user, any  type)  &  controls(any  software_sy stem, type)  => 
uses(user,software_system) 

type  supplier 
a_kind_of(supplier,  agent) 
supplies(every  supplier.an  object) 

type  vendor 

a Jkind_of(vendor,  supplier) 
sells(every  vendor.a  product) 

type  customer 
a_kind_offcustomer, agent) 
buys(every  customer, a  product) 

relation  buys(customer, object) 

--  Means  the  customer  buys  instances  of  the  object. 
buys(any  customer, any  object)  =>  buys_from(customer, object, a  vendor) 

relation  buys_from(customer, object, vendor) 

—  Means  the  customer  buys  the  object  from  the  vendor. 
buys_from(any  customer, any  object, any  vendor)  ■> 

pays(customer, vendor) 
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relation  pays(customer .vendor) 

—  Means  the  customer  sends  money  to  the  vendor. 

relation  supplies(supplier, object) 

—  Means  the  supplier  creates  and  delivers  instances  of  the  object. 

relation  sells(vendor,object) 

—  Means  the  vendor  sells  instances  of  the  object. 
sells(any  vendor.any  object)  =>  supplies(vendor, object) 

--  To  sell  something,  a  vendor  must  supply  it. 
sells(any  vendor.any  object)  =>  buys(a  customer, object) 

—  To  sell  something,  someone  must  buy  it. 

relation  needed_for(object, activity) 

—  Means  an  instance  of  the  object  is  needed  for  the  activity  to  occur. 

relation  wants(agent, object) 

—  Means  the  agent  is  motivated  to  acquire  the  object. 
wants(any  agent.any  activity)  &  needed_for(any  object, activity)  => 

wants(agent, object) 

—  People  want  the  means  to  achieve  their  ends. 
wants(any  customer.any  object)  =>  buys(customer, object) 

—  Customers  are  agents  with  the  resources  to  satisfy  their  wishes. 
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APPENDIX  B 


MODEL  LANGUAGE  GRAMMAR 

The  grammar  for  the  Model  language  used  In  the  requirements 

analysis  is  shown  below  as  taken  from  Ref.  19.  Terminal  symbols 

appear  in  double  quotes.  Repetitions  are  indicated  by  x*  (zero  or  more 

x’s)  or  x+  (one  or  more  x’s).  Alternatives  are  separated  by  vertical 

bars.  Ranges  of  single  character  alternatives  are  shown  [0-2] 

(meaning  "0"  I  "1"  I  "2"). 

model  =  (type  I  relation)* 

type  =  "type"  name  law*  attribute* 

relation  =  "relation"  name  "("name_list")"  law* 

attribute  =  name  "("name_list")"  ":"  name 

law  =  relationship  I  "-"  law  I  law  op  law  I  "("  law  ")" 

relationship  =  name  "("  arg_list")" 

op  =  "&"  I  "I"  I  "=>"  I  "<=>" 

name_list  =  name  (","  name)* 

argjist  =  arg  (","  arg)* 

arg  =  variable  I  attribute_value 

variable  =  prefix  name  digit*  dependency 

attribute_value  =  arg  name  dependency 

prefix  =  "a"  I  "an"  I  "every"  I  "any"  I  "" 

dependency  =  "("argjist")"  I  ”" 

name  =  alpha+  ("_"  alpha+)* 
alpha  =  (a-zj  I  IA-Z] 
digit  =  [0-9] 

All  ops  are  left  associative:  a  op  b  op  c  means  (a  op  b)  op  c. 

Precedence  order:  (strongest)  I,  ■>,  <=>  (weakest). 

Comments  extend  from  the  leftmost  "  to  the  end  of  the  line. 


54 


APPENDIX  C 


TDL  DEFINITION  EXAMPLES 

The  TDL  definitions  have  all  been  successfully  compiled  and  tested. 

Testing  consisted  of  actual  operation  of  the  Design  Database  using  an 

example  prototype.  The  tests  were  conducted  by  invoking  each 

application  or  operation  with  the  correct  format  in  the  input  file 

"ddb.in".  All  exception  definitions  were  tested  by  intentionally  invoking 

each  operation. 

Node  definition 

define  Type  Node 

supertypes  =  (Entity}; 

properties  = 

( 

name;  String; 
specification:  String; 
implementation:  optional  String; 
controlconstraints:  optional  String; 
graphicrecord:  optional  String; 

subNodes:  distributed  Set[Node]  inverse  $Node$isChildOf; 
isChildOf:  optional  Node  inverse  $Node$subNodes; 

I; 


operations  = 

( 

buildDlsplay  (n:Node) 
retums(Node) 

method  (NodeBuildDisplay); 

listSubnodes  (n:Node) 
returns  (Set[Node]) 
method  (NodeListSubNodes); 

listSubnodesIntemal  (n:  Node ,  s:  Set[Node]) 
returns  (Set(NodeJ) 
method  (NodeListSubNodesInt); 
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refines  delete  (n:  Node) 
raises  (CannotDelete) 
triggers(NodeDeleteTrigger) ; 


define  Procedure  Create 

(t:Type, 

keywords 
name:  String, 
specification:  String, 
optional  Implementation:  String, 
optional  controlconstraints:  String, 
optional  graphicrecord:  String, 
optional  isChildOf:  Node, 
optional  where:  Entity, 
optional  hownear:  Clustering) 

returns  (Node) 

raises  (NodeAlreadyExists) 

triggers  (NodeCreateTttgger) 

supertypes  =  |$Entity$Create); 

end  Create; 

define  Procedure  Lookup  (s:String) 
returns  (Node) 
raises  (NodeNotlnCatalog) 
method  (NodeLookup) 
supertypes  =  {Entity}; 

end  Lookup; 

end  Node; 

define  UnorderedDictionary  NodeCatalog 
memberspec  =  Node; 
indexSpec  =  String; 

end  NodeCatalog; 

define  Variable  NodeCatalogVar:  UnorderedDictionary  [Node,  String! 

NodeCatalog; 

define  variable  NodeSerialNumber:  Integer  :=  I; 
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Exception  definitions 

define  Exceptioniype  NodeException 

supertypes  =  {Exception}; 
properties  = 

{ 

nodeName:  String; 

}; 

end  NodeException; 

define  Exceptioniype  NodeNotlnCatalog 

supertypes  =  (NodeException); 
end  NodeNotlnCatalog; 

define  Exceptioniype  NodeAlreadyExists 

supertypes  =  {NodeException}; 
end  NodeAlreadyExists; 
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APPENDIX  D 


COP  OPERATIONS  CODE 

The  COP  definitions  have  all  been  successfully  compiled  and 
tested.  Testing  consisted  of  actual  operation  of  the  Design  Database 
using  an  example  prototype.  The  tests  were  conducted  by  invoking 
each  operation  with  the  correct  format  in  the  input  file  "ddb.in".  All 
exception  definitions  were  tested  by  intentionally  invoking  each 
operation. 

String  Definitions 

/*  This  file  contains  all  the  symbolic  constant  definitions  used  */ 

/*  in  the  COP  operation  and  application  programs  */ 

#define  LINELENGTH  80  /*  Linelength  is  80  characters  */ 

#define  MAXLINE  81  /*  Maximum  linelength  is  81  characters  */ 

/*  including  the  null  (\0)  character  •/ 

#define  LINEBUFFER  82  /*  Temporary  buffer  used  to  hold  Maxline  */ 
#define  MAXSTRING  4000  /*  Maximum  length  of  a  String  in  Vbase  */ 

Node  Methods 

/*  Program  -  Node.c  */ 

/*  This  program  implements  the  methods  defined  in  Node.tdl  */ 

/*  The  methods  implemented  are  */ 


/*  Node  Build  Display  */ 

/*  Node  List  SubNodes  */ 

/*  Node  List  SubNodes  Internal  */ 
/*  Node  Lookup  */ 

/*  Node  Create  Trigger  */ 

/*  Node  Delete  Trigger  */ 


#include  <stdio.h>  /•  include  standard  C  routines  */ 
#include  <string.h> 

#include  "string.def  /*  include  string  definitions  file  */ 
char  opnametMAXLINE];  /*  Local  variable  declarations  */ 
FILE  *out; 

char  spectextrMAXSTRING], 
imptext  [MAXSTRING] , 
cctextJMAXSTRIN  G] ; 
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import  $Type; 
import  $Class; 

enter  module  $Node; 

method 
obj  $Node 

NodeBuildDisplay(aNode) 

obj  $Node  aNode; 

{ 

out  =  fopen("ddb.out",  "a"); 


/*  Convert  Object  Code  to  C  Code  */ 

AM_stringToC  (aNode.  name,  op  name ,  sizeof(opname)) ; 
fprintf(out ,  "%s\ n" ,  opname) ; 

AM_stringToC  (aNode .  specification ,  spectext ,  sizeoflspectext)); 
fprintf  (out,"%s\n",  spectext); 


if  (hasvalue(aNode.implementation)) 

( 

AM_stringToC(aNode.implementation,  imp  text,  sizeoflimptext)); 
fprintflout,  "%s\n",  imptext); 

I 

if  (hasvalue(aNode.  controlconstraints)) 

( 

AM_stringToC(aNode . controlconstraints ,  cctext,  sizeof(cctext)); 
fprintf(out,  "%s\n",  cctext); 

) 

fclose(out); 

retum(aNode); 


method 

obj  $Set[obj  $Node) 

NodeListSubNodes(aNode) 
obj  $Node  aNode; 

( 

obj  $Set[obj  $Node]  theSubNodes; 
theSubNodes  =  $Set(obj  $Node)$l); 
$Node$ListSubNodesIntemal(aNode ,  theSubNodes) ; 
retum(theSubNodes) ; 
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method 

obj  $Set{obj  $Node] 

NodeListSubNodesInt(aNode,  theSubNodes) 

obj  $Node  aNode; 

obj  $Set[obj  $Node]  theSubNodes; 

I 

obj  $Node  currentNode; 
lterate(currentNode  =  aNode.  SubNodes) 

I 

$Set$Insert(theSubNodes,  currentNode); 
$Node$ListSubNodesIntemal(currentNode,  theSubNodes); 
I 

retum(theSubNodes) ; 


method 
obj  $Node 

NodeLookup(aNodeName) 
obj  $Strlng  aNode  Name; 

{ 

obj  $Node  theNode; 
theNode  = 

$UnorderedDictionary$GetElement($NodeCatalogVar,aNodeName); 
except(enf:  ElementNotFound) 

I 

raJse  NodeNotlnCatalogfnodeName:  aNodeName); 

) 

retum(theNode) ; 

) 

method 
obj  $Node 

NodeCreateTrigger(aType,  name,  specification,  implementation, 
controlconstraints,  graphicrecord, 
isChildOf,  where,  hownear) 

obj  $iype  aType; 
keyword  obj  $String  name; 
keyword  obj  $String  specification; 
keyword  obj  $String  implementation; 
keyword  obj  $String  controlconstraints; 
keyword  obj  $String  graphicrecord; 
keyword  obj  $Node  isChildOf; 
keyword  obj  $Entity  where; 
keyword  obj  $Clustering  hownear; 
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{ 

obj  $Node  theNode; 

{ 

theNode  =  $Node$Lookup(name); 

raise  NodeAlreadyExists(nodename:name); 


} 

except  (nnc:  NodeNotlnCatalog) 

I 

theNode  *  $$(aType,  namername,  specification : specification , 
implementation.implementation, 
controlconstraints :  controlconstraints , 
graphicrecord :  graphicrecord , 
isChildOfdsChildOf, 
whererwhere,  hownearrhownear); 

$UnorderedDictionaiy$Insert($NodeCatalogVar,name, theNode); 

retum(theNode) ; 

) 

} 

method 

void 

NodeDeleteTrigger(aNode) 

obj  $Node  aNode; 

( 

obj  $Node  theNode; 
iterate(theNode  =  aNode.  subNodes) 

$UnorderedDictionary$Remove($NodeCatalogVar,theNode.name); 

$$(aNode); 

I 
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APPENDIX  E 


APPLICATION  PROGRAMS 

The  application  programs  have  all  been  successfully  compiled  and 
tested.  Testing  consisted  of  actual  operation  of  the  Design  Database 
using  an  example  prototype.  The  tests  were  conducted  by  invoking 
each  application  or  operation  with  the  correct  format  in  the  input  file 
"ddb.in".  All  exception  definitions  were  tested  by  intentionally  invoking 
each  operation. 


Create  Root  Node 

/*  Program  CreateRootNode  */ 

/*  This  program  is  used  to  create  a  Node  which  will  be  the  root  of  */ 
/*  a  tree  structure.  It  interfaces  with  the  User  Interface  through  */ 

/*  a  file  called  ddb.in.  */ 

/*  The  program  reads  in  the  required  information  from  ddb.in  */ 
/*  then  creates  the  Node  and  inserts  it  as  the  root  node  */ 

/*  The  required  information  in  ddb.in  is  */ 

/*  Node  Name  */ 

/*  Specification  */ 

/*  Implementation  (Optional)  V 

/*  Control  Constraints  (Optional)  */ 

#include  <stdio.h>  /*  include  Standard  C  routines  */ 

#include  <string.h> 

#include  "string,  def  /*  include  string  definitions  file  */ 

/*  Local  variable  declarations  */ 
char  tempnamelMAXLINE], 
opname[MAXLINE  j , 
templine(MAXLINE) , 
tempgr(MAXLINEl ; 

char  Temptext(LINEBUFFER) , 

Graphtext(LINEBUFFER); 

char  Spectext[MAXSTRING), 

Imptext(MAXSTRING) , 

Cctext  [MAXSTRING] , 

GrlinklMAXSTRING] ; 
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FILE  *in,  *gr; 
int  linelength; 
int  1; 

Import  $Node; 


main  (argc,  argv) 
int  argc; 
char  **argv; 

{ 

char  *dbname; 
char  *getenvO; 

obj  $Node  theNode;  /*  local  object  variables  */ 
obj  $String  the  name, 
the  spec, 
theimp, 
thecc, 
thegraph; 

if  (argc  >  1) 

{ 

dbname  =  argv[l]; 

} 

else  if  (dbname  =  getenv("DBNAME"}) 

I 

) 

else 

I 

printf("Must  specify  database  name,  either  as  a  command  line 
argument, \nor  via  the  Unix  environment  variable  DBNAMEXn"); 
exit(l); 

} 

{ 

AM_databaseOpen  (dbname,  0); 
in  *=  fopenC'ddb.in",  "r'j; 

fgets(tempname,  LINELENGTH,  in);  /*  Read  the  name  of  the  Node  */ 
stmcpy(opname,  tempname,  (strlen(tempname)  -  1)); 
fgets(templine,  LINELENGTH,  in);  /*  Read  first  property  */ 
if  (stmcmpC'SPECIFICATION",  templine,  13)  ~  0) 

/*  Verify  Specification  is  first  Property  V 

I 

stmcpy(Spectext, templine,  strlen(templine)); 

strcat(Spectext,  "Nn'j; 

templinelOJ  =  ’\0’; 

for(i  «  0;  i  <  MAXLINE;  i++) 

Temptextli]  =  ’\0‘; 
fgets(templine,  LINELENGTH,  in); 
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whHe(stmcmp(”IMPLEMENTATION", templine,  14)  !=  0) 

/*  Read  in  Specification  Until  Implementation  Begins  */ 

{ 

stmcpy(Temptext,  templine, strlen(templine)); 

strcat(Temptext,  ”\n"); 

strcat(Spectext,  Temptext); 

templinelO]  =  ’\0’; 

for(i  *  0;  1  <  MAXLINE;  1++) 

TemptextU]  =  ’\0’; 
fgets(templine,  LINELENGTH,  in); 

) 

Cctext[0]  =  ’NO’; 

Grlink[0]  «  ’\0’; 

stmcpy(Temptext,  templine,  strlen(templine)); 
strcat(Temptext,  "\n"); 
strcat(Imptext,  Temptext); 
templlne[0]  =  '\0’; 

ford  ■  0;  1  <  MAXLINE;  1++) 

TemptextU!  =  ’\0’; 
fgetsdempline,  LINELENGTH,  in); 

/*  If  Implementation  is  graph  then  read  in  graphic  record  */ 

if  (stmcmpC'GRAPH",  templine,  5)  ==  0) 

I 

gr  =  fopenf'llnks.c",  "r"); 
fgets(tempgr,  LINELENGTH,  gr); 
while  (feofigr)  -■  0) 

{ 

stmcpy(Graphtext,  tempgr,  strlen(tempgr)); 

strcat(Graphtext,  "\n"); 

strcat(Grllnk,Graphtext) ; 

tempgrlO]  =  ’NO'; 

for  d  =  0;  i  <  MAXLINE;  1++) 

Graphtextli]  *  ’\0’; 
fgets(tempgr,  LINELENGTH,  gr); 

} 

) 

fclose(gr); 

stmcpy (Temptext,  templine,  strlen(templine)); 

strcat(Temptext,  "\n"); 

strcat(Imptext,  Temptext); 

templinelO]  =  ’\0'; 

for  (1  =  0;  1  <  MAXLINE;  1++) 

TemptextU]  =  ’\0’; 
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while  (feoflin)  ==  0) 


fgets(templine,  LINELENGTH,  in); 
ifIstmcmp("CONTROL  CONSTRAINTS",  templine,  19) 
/*  Read  in  Control  Constraints  */ 

{ 

while(feoflin)  ==  0) 

{ 

stmcpy(Temptext,  templine,  strlen(templine)); 

strcat(Temptext,  "\n"); 

strcatfCctext,  Temptext); 

templinelO]  =  ’\0’; 

for  (i  =0;  i  <  MAXLINE;  i++) 

Temptext(i)  =  ’\0’; 
fgets(templine,  LINELENGTH,  in); 

) 

1 

else 

/ *  Read  in  Implementation  */ 

I 

stmcpy(Temptext,  templine,  strlen(templine)); 

strcat(Temptext,  "\n"); 

strcatflmptext,  Temptext); 

templinelO]  «=  ’\0’; 

for  (i  =  0;  i  <  MAXLINE;  i++) 

Temptextli]  =  ’\0’; 
fgets( templine,  LINELENGTH,  in); 


) 

else 

I 

printfl'  Input  file  is  not  in  the  correct  format."); 
exit(l); 

} 

fclose(in); 

/*  Assign  C  variables  to  Object  Variables  */ 
thename  =  opname; 
thespec  =  Spectext; 
theimp  =  Imptext; 

/*  Execute  Create  depending  on  the  properties  */ 
if  ((strlen(Cctext)  ==  0)  &&  (strlen(Grlink)  «  0)) 

I 

theNode  *  $Node$lname:thename,speciflcation:thespec, 
implementation:theimp]; 
except(nae:NodeAlreadyExists) 
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theNode  =  $Node$Lookup(thename); 

} 

} 

else  if  ((strlen(Cctext)  ==  0)  &&  (strlen(Grlink)  !=  0)) 

{ 

thegraph  =  Grllnk; 

theNode  =  $Node$(name:thename,  specification:thespec, 
implementatlon:theimp,  graphic  record :  thegraphj ; 
except(nae:NodeAlreadyExists) 
l 

theNode  =  $Node$Lookup(thename); 


else 

{ 

thecc  =  Cctext; 

theNode  =  $Node$[name:thename,  speciflcation:thespec, 
implementation:theimp,  controlconstraints: thecc]; 
except(nae:NodeAlreadyExists) 

{ 

theNode  =  $Node$Lookup(thename); 

} 

} 

} 

protect 

AM_databaseClose(dbname) ; 


Create  Child  Node 

/*  Program  Create  Child  Node  */ 

/*  This  program  is  used  to  create  a  Node  which  will  a  child  of  */ 
/*  a  node  in  the  tree  structure.  It  interfaces  with  the  User  */ 

/*  Interface  through  a  file  called  ddb.in.  •/ 

/*  The  program  reads  in  the  required  information  from  ddb.in  */ 
/*  then  creates  the  Node  and  inserts  in  the  proper  order  */ 

/*  The  required  information  in  ddb.in  is  */ 


/*  Node  Name  */ 

/*  Parent  Node  Name  */ 

/*  Specification  */ 

/•  Implementation  (Optional)  •/ 

/*  Control  Constraints  (Optional)  */ 
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#include  <stdio.h>  /*  include  standard  C  routines  */ 
#include  <string.h> 

#include  "string.def’  /*  include  string  definitions  file  */ 
/*  local  variables  */ 
char  tempnamefMAXLINE], 
opname[MAXLINE] , 
templinefMAXLINE] , 
tempgrIMAXLINEl; 
char  tempparent[MAXLINE], 
parentname(MAXLINE] , 

char  TemptextILINEBUFFERJ , 

Graphtext[LINEBUFFER] ; 

char  SpectextfMAXSTRIN G j , 

Imptext  [MAXSTRING] , 

Cctext  [MAXSTRING] , 

Grlink[MAXSTRING] ; 

FILE  *in,  *gr; 
int  linelength; 
int  i; 

import  $Node; 
main  (argc,  argv) 

int  argc; 
char  **argv; 

{ 

char  *dbname; 
char  *getenv(); 

obj  $Node  theNode, 

parentNode;  /*  local  object  Variables  */ 

obj  $String  thename, 
the  spec, 
the  imp, 
thecc, 
thegraph, 
theparent; 

if  (argc  >  1) 

( 

dbname  =  argv[l]; 

I 

else  if  (dbname  =  getenv("DBNAME")) 
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I 

else 

{ 

printf("Must  specify  database  name,  either  as  a  command  line 
argument, \nor  via  the  Unix  environment  variable  DBNAMEXn"); 
exit(l); 

} 

{ 

AM_databaseOpen  (dbname,  0); 
in  =  fopenf'ddb.in",  "r"); 

fgetsftempname,  LINELENGTH,  in);  /*  Read  the  name  of  the  Node  */ 
stmcpy (opname ,  tempname,  (strlen(tempname)  -  1)); 
fgets(tempparent,  LINELENGTH,  in);  /*  Read  the  parent  Node  name  */ 

stmcpy (parentname,  tempparent,  (strlen(tempparent)  -  1)); 
fgetsftempline,  LINELENGTH,  in);  /*  Read  in  the  property  */ 

/*  Verify  Specification  is  first  Property  */ 
if  (stmcmp(  "SPECIFICATION”,  templine,  13)  ==  0) 

{ 

stmcpy(Spectext,templine,  strlenf templine)); 

strcat(Spectext,  "\n"'); 

templine[0]  =  ’\0’; 

for(i  =  0;  i  <  MAXLINE;  i++) 

Temptextli]  =  ’NO’; 
fgets(templine,  LINELENGTH,  in); 

while(stmcmp(''IMPLEMENTATION'', templine,  14)  !=  0) 

/*  Read  in  Specification  Until  Implementation  Begins  */ 

{ 

stmcpy(Temptext,  templine, strlen(templine)); 

strcat(Temptext,  "Nn"); 

strcatf  Spec  text,  Temptext); 

templine(O)  =  ’NO’; 

for(i  =  0;  i  <  MAXLINE;  i++) 

Temptextli)  =  ’NO’; 
fgets(templine,  LINELENGTH,  in); 

) 

Cctext[0]  =  ’NO"; 

GrlinklO]  =  ’NO’; 

stmcpyfTemptext,  templine,  strlen(templine)); 

strcat(Temptext,  "Nn"); 

strcatflmptext,  Temptext); 

tempIine[OJ  =  'NO'; 

for(i  =  0;  i  <  MAXLINE;  i++) 

Temptextli]  =  ’NO’; 
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/*  If  Implementation  is  graph  then  read  in  graphic  record  */ 
fgets(templine,  LINELENGTH,  in); 
if  (stmcmpC'GRAPH",  templine,  5)  ==  0) 

{ 

gr  =  fopenf'links.c",  "r"); 
fgets(tempgr,  LINELENGTH,  gr); 
while  (feoflgr)  ■■  0) 

( 

stmcpy(Graphtext,  tempgr,  strlen(tempgr)); 

strcat(Graphtext,  "\n"); 

strcat(Grlink,  Graphtext) ; 

tempgrIO]  =  ’\0'; 

for  (i  -  0;  i  <  MAXLINE;  i++) 

Graphtext[i)  =  ’\0’; 
fgets(tempgr,  LINELENGTH,  gr); 

I 

) 

fclose  (gr); 

stmcpyfTemptext,  templine,  strlen(templine)); 

strcat(Temptext,  "\n"); 

strcat(Imptext,  Temptext); 

templine  [0]  =  ’\0’; 

for  (i  =  0;  i  <  MAXLINE;  i++) 

Temptext[i]  =  '\0’; 

while  (feof(in)  ==  0) 

I 

fgets(templine,  LINELENGTH,  in); 

if(stmcmp("CONTROL  CONSTRAINTS",  templine,  19)  == 
/*  Read  in  Control  Constraints  */ 

{ 

while(feof(in)  ==  0) 

I 

strncpy(Temptext,  templine,  strlen(templine)); 

strcat(Temptext,  "\n"); 

templine|0J  *  ’NO’; 

for  (i  =0;  i  <  MAXLINE;  i++) 

TemptextUl  *  ’\0’; 
fgets(templine,  LINELENGTH,  in); 

I 

) 

else 

{ 

stmcpyfTemptext,  templine,  strlen(templine)); 
strcat(Temptext,  "\n"); 
strcat(Imptext,  Temptext); 
templinelO]  =  ’\0’; 
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for  (i  =  0;  i  <  MAXLINE;  i++) 

Temptextfi]  =  ’\0'; 

} 

} 

I 

else 

{ 

printfC'Input  file  is  not  In  the  correct  format."); 
exit(l); 

} 

fclose(tn); 

/*  Assign  C  variables  to  Object  Variables  */ 

theparent  =  parentname; 

thename  =  opname; 

thespec  =  Spectext; 

theimp  =  Imptext; 

parentNode  =  $Node$Lookup(theparent) ; 

/*  Execute  Create  depending  on  the  properties  */ 
if  ((strlen(Cctext)  ==  0)  &&  (strlen(Grlink)  =«*  0)) 

I 

theNode  =  $Node$[name:thename,specification:thespec, 

implementation:theimp,  isChildOfrparentNode] ; 
except(nae:NodeAlreadyExists) 


{ 

theNode  =  $Node$Lookup(thename); 

) 

> 

else  if((strlen(Cctext)  ==  0)  &&  (strlen(Grlink)  t=  0)) 

{ 

thegraph  =  Grlink; 

theNode  =  $Node$[name:thename,  specification: thespec , 
implementation: theimp,  graphicrecord:thegraph, 
isChildOf:  parentN  ode] ; 
except(nae:  NodeAlreadyExists) 
l 

theNode  =  $Node$Lookup(thename); 

} 

I 

else 

I 

thecc  =  Cctext; 

theNode  =  $Node$[name: thename,  specification:thespec, 
implementation:theimp,  controlconstraints: thecc, 
isChildOfiparentNode] ; 
except(nae:  NodeAlreadyExists) 


theNode  =  $Node$Lookup(thename); 

} 

} 

I 

protect 

AM_databaseClose(dbname) ; 


Store  Property 

/*  Program  Store  Property  */ 

/*  This  program  is  used  to  store  or  change  a  Node  property.  */ 
/*  It  interfaces  with  the  User  Interface  through  a  file  called  */ 

/*  ddb.in.  */ 

/*  The  program  reads  in  the  required  information  from  ddb.in  */ 
/*  then  inserts  the  new  property  into  the  Node  */ 

/*  The  required  information  in  ddb.in  is  */ 

/*  Node  Name  */ 

/*  Property  Name  */ 

#include  <stdio.h>  /*  include  standard  C  routines  */ 

#include  <string.h> 

#include  "string.def  /*  include  string  definitions  file  •/ 

/*  local  variables  */ 
char  opname[MAXLINE], 
tempname[MAXLINE] , 
templine[MAXLINEj ; 

char  nodepropertylMAXSTRING]; 
char  temptext[LINEBUFFERl; 

FILE  *in; 
int  i; 

import  $Node; 

main(argc,  argv) 

int  argc; 
char  **argv; 


char  ‘dbname; 
char  *getenv(); 

obj  $Node  theNode;  /*  local  object  variables  */ 
obj  $String  theOperator, 
theProperty; 
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If  (argc  >  1) 

{ 

dbname  =  argv(l); 

} 

else  if  (dbname  =  getenvf'DBNAME'j) 

{ 

> 

else 

( 

printf(''Must  specify  database  name,  either  as  a  command  line 
argument,  \nor  via  the  unix  environment  variable  command"); 
exit(l); 

I 

{ 

AM_databaseOpen  (dbname,  0); 
in  =  fopen("ddb.in",  "r"); 

fgets(tempname,  LINELENGTH,  in);  /*  Read  in  the  Node  name  */ 
stmcpyfopname,  tempname,  (strlen(tempname)  -  1)); 
fgets(templine,  LINELENGTH,  in);  /*  Read  in  the  property  name  */ 
do 
{ 

stmcpy(temptext,  templine,  (strlen(templine)  -  1)); 
strcat(temptext,  "\n"); 
strcat(nodeproperty,  temptext); 
templine[0]  =  ’\0’; 
for(i  =  0;  i  <  MAXLINE;  i++) 
temptext[i]  a  ’\0’; 
fgets(templine ,  LINELENGTH,  in); 

) 

while(feof(in)  ==  0); 

/*  Assign  c  variables  to  object  variables  */ 
theOperator  =  opname; 
theProperty  =  nodeproperty; 

/*  Verify  the  Node  exists  */ 
theNode  =  $Node$Lookup(theOperator); 

/*  Assign  the  property  to  its  correct  property  */ 
if  (stmcmp("SPECIFICATION",  nodeproperty,  13)  «=«  0) 

I 

theNode.specification  *  theProperty; 


} 

else  if  (stmcmpC'IMPLEMENTATION",  nodeproperty,  14)  ««  0) 

{ 


I 


theNode.implementation  =  theProperty; 


else  if  (stmcmpf'CONTROL  CONSTRAINTS",  nodeproperty,  19)  «■  0) 

{ 
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theNode.controlconstralnts  =  theProperty; 

) 

else 

( 

theNode.graphicrecord  =  theProperty; 

} 

fclose(in); 

} 

protect 

AM_databaseClose(dbname) ; 

) 


Get  Property 

/*  Program  Get  Property  */ 

/*  This  program  is  used  to  retrieve  a  Node  property.  */ 

/*  It  interfaces  with  the  User  Interface  through  two  files  */ 

/*  ddb.in  &  ddb.out  */ 

/*  The  program  reads  in  the  required  information  from  ddb.in  */ 
/*  then  outputs  the  requested  information  to  ddb.out  */ 

/*  The  required  information  in  ddb.in  is  */ 

/*  Node  Name  */ 

/*  Property  Name  */ 

/*  The  information  output  to  ddb.out  */ 

/*  Property  requested  */ 


#include  <stdio.h>  /*  include  standard  C  routines  */ 
#include  <string.h> 

#include  "string.def  /*  include  string  definitions  file  */ 
/*  local  variables  */ 
char  opnamefMAXLINE], 
tempname{MAXLINE] , 
templinefMAXLINE] ; 
char  nodeproperty[MAXSTRING]; 
char  temptext[LINEBUFFER]; 

FILE  *in,  *out; 
int  i; 


import  $Node; 
main(argc,  argv) 
int  argc; 
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char  **argv; 


char  *dbname; 
char  *getenv(); 

obj  $Node  theNode;  /*  local  object  variables  */ 
obj  $String  theOperator, 
theProperty; 

If  (argc  >  1) 

{ 

dbname  =  argv[l]; 

} 

else  if  (dbname  =  getenv("DBNAME'j) 

{ 

I 

else 

{ 

printf("Must  specify  database  name,  either  as  a  command  line 
argument,  \nor  via  the  unix  environment  variable  command"); 
exit(l); 


I 

AM_databaseOpen  (dbname,  0); 
in  =  fopenf  ddb.in",  Vj; 
out  =  fopenf'ddb.out",  "w'j; 

fgets(tempname,  LINELENGTH,  in);  /*  read  in  Node  name  */ 
stmcpy(opname,  tempname,  (strlen(tempname)  -  1)); 
fgets(templine,  LINELENGTH,  in);  /*  read  in  property  name  */ 
/*  Assign  C  variable  to  object  variable  */ 
theOperator  =  opname; 


/*  Verify  Node  exists  */ 
theNode  =  $Node$Lookup(theOperator); 

/*  Determine  correct  property  to  output  */ 
if  (stmcmpC'SPECIFICATION",  templine,  13)  ==  0) 

I 

/*  Assign  property  */ 
theProperty  =  theNode.  specification; 

/*  Convert  object  type  to  C  type  •/ 

AM_stringToC( theProperty,  nodeproperty,  sizeof(nodeproperty)); 
/*  Output  to  ddb.out  */ 
fprintf(out,  "%s\n",  nodeproperty); 


else  if  (stmcmpC'IMPLEMENTATION".  templine,  14)  ==  0) 

( 

/*  Assign  property  */ 

theProperty  =  theNode.implementation; 

/*  Convert  object  type  to  C  type  */ 

AM_stringToC(  theProperty,  nodeproperty,  sizeof(nodeproperty)); 
/*  Output  to  ddb.out  */ 
fprintflout,  "%s\n",  nodeproperty); 

) 

else  if  (stmcmpC'CONTROL  CONSTRAINTS",  templine,  19)  «=*»  0) 

{ 

/*  Assign  property  */ 

theProperty  =  theNode.controlconstraints; 

/*  Convert  object  type  to  C  type  */ 

AM_stringToC( theProperty,  nodeproperty,  sizeof(nodeproperty)); 
/*  Output  to  ddb.out  */ 
fprintflout,  "%s\n",  nodeproperty); 

1 

else 

{ 

/*  Assign  property  */ 

theProperty  =  theNode.graphicrecord; 

/•  Convert  object  type  to  C  type  */ 

AM_stringToC(theProperty,  nodeproperty,  sizeof{nodeproperty)); 
/*  Output  to  ddb.out  */ 
fprintflout,  "%s\n",  nodeproperty); 

) 

fclose(in); 

fclose(out); 

) 

protect 

AM_databaseClose(dbname) ; 


Get  Parent 

/•  Program  Get  Parent  */ 

/*  This  program  is  used  to  retrieve  the  name  of  a  Node’s  parent  */ 
/*  It  interfaces  with  the  User  Interface  through  ddb.in  */ 

/*  &  the  standard  output  device  */ 

/*  The  program  reads  in  the  required  information  from  ddb.in  */ 
/*  then  pipes  the  requested  information  to  the  standard  output  */ 
/*  The  required  information  in  ddb.in  is  */ 

/*  Child  Node  Name  •/ 

/*  The  information  output  to  standard  output  */ 

/•  Parent  Node  Name  */ 


75 


#include  <stdio.h>  /*  include  standard  c  routines  */ 
#include  <string.h> 

#include  "string.def'  /*  include  string  definitions  file  */ 
/*  local  variables  */ 

FILE  *in; 

char  parentnamefMAXLINE] , 
tempname(MAXLINEl , 
childname[MAXLINE] ; 

import  $Node; 

main(argc,  argv) 

int  argc; 
char  **argv; 

{ 


char  'dbname; 
char  'getenvO; 
obj  $Node  theNode, 

parentNode;  /*  local  object  variables  */ 
obj  $String  theChild, 
theParent; 

if  (argc  >  1) 

I 

dbname  *  argv[lj; 

} 

else  if  (dbname  =  getenv("DBNAME'j) 

( 

} 

else 

( 

printf("Must  specify  database  name,  either  as  a  command  line 
argument, \nor  via  the  Unix  environment  variable  DBNAMEXn'j; 
exit(l); 

) 

i 

AM_databaseOpen(dbname,  0); 
in  =  fopen("ddb.in",  "r'j; 

fgets(tempname,LINELENGTH,  in);  /*  read  in  Child  Node  Name  */ 
stmcpyfchildname,  tempname,  (strlen(tempname)  -  1)); 

/*  Assign  c  variable  to  object  variable  */ 
theChild  =  child  name; 

/*  Verify  Node  exists  */ 
theNode  =  $Node$Lookup(theChild); 
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/*  Assign  Parent  Name  */ 
parentNode  =  theNode.isChildOf; 

/*  Convert  to  c  code  */ 

AM_stringToC(parentN ode. name,  parentname,  sizeofjparentname)) ; 
/*  Output  to  standard  output  device  */ 
printfT%s\n",  parentname); 
fclose(in); 

protect 

AM_databaseClose(dbname) ; 


Get  Children 

/*  Program  Get  Children  */ 

/*  This  program  is  used  to  retrieve  the  name  of  a  Node’s  */ 
/*  Child  or  Children.  It  interfaces  with  the  User  Interface  */ 

/*  through  ddb.in  &  ddb.out  V 

/*  The  program  reads  in  the  required  information  from  ddb.in  */ 
/*  then  outputs  the  requested  information  to  ddb.out  */ 

/*  The  required  information  in  ddb.in  is  */ 

/*  Parent  Node  Name  */ 

/*  The  information  output  to  ddb.out  */ 

/*  Child  Node  Name(s)  */ 

#include  <stdio.h>  /*  include  standard  c  routines  */ 

#include  <string.h> 

#include  "string.def  /*  include  string  definitions  file  */ 

/*  local  variables  */ 

FILE  *in,  *out; 
char  opnamefMAXLINE] , 
tempname[MAXLINE] , 
childname  [MAXLINE1 ; 

import  $Node; 

main(argc,  argv) 

int  argc; 
char  **argv; 

( 

char  ‘dbname; 

char  *getenv();  /*  local  object  variables  */ 
obj  $Node  theNode, 
currentNode; 
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obj  $Set[obj  $NodeJ  theNodes; 
obj  $String  theParent; 

if  (argc  >  1) 

{ 

dbname  =  argv[l]; 

} 

else  if  (dbname  =  getenv("DBNAME")) 

{ 

} 

else 

( 

printff'Must  specify  database  name,  either  as  a  command  line 
argument, \nor  via  the  Unix  environment  variable  DBNAMEXn"); 
exit(l); 

) 


( 

AM_databaseOpen(dbname,  0); 
in  =  fopen("ddb.in",  "r"); 
out  =  fopen("ddb.out",  "w"); 

fgets(tempname,LINELENGTH,  in);  /*  read  in  parent  node  name  */ 
stmcpy(opname,  tempname,  (strlen(tempname)  -  1)); 

/*  assign  to  object  variable  */ 
theParent  =  opname; 

/*  verify  node  exists  */ 

theNode  =  $Node$Lookup(theParent); 

/*  assign  children  names  to  variable  */ 
theNodes  =  theNode.  subNodes; 

/*  iterate  through  the  set  */ 
iterate(currentNode  =  theNodes) 

{ 

/*  Convert  object  code  to  C  code  */ 

AM_stringToC(currentN ode. name,  childname,  sizeofl(childname)); 

/*  Output  to  ddb.out  */ 
fprintffout,  "%s\n",  childname); 

) 

fclose(in); 

fclose(out); 

} 

protect 

AM_databaseClose(dbname); 
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Delete  Node 

/*  Program  Delete  Node  */ 

/*  This  program  is  used  to  delete  a  Node  from  the  tree  */ 

/*  It  also  deletes  any  child  Nodes  coming  from  the  Node  */ 

/*  It  interfaces  with  the  User  Interface  through  ddb.in  */ 

/*  The  program  reads  in  the  required  information  from  ddb.in  */ 
/*  then  deletes  the  node  and  all  of  its’  children  */ 

/•  The  required  information  in  ddb.in  is  */ 

/*  Node  Name  */ 

#include  <stdio.h>  /*  include  standard  C  routines  */ 

#include  <string.h> 

#include  "string.def'  /*  include  string  definitions  file  */ 

/*  Local  variables  */ 
char  opname[MAXLINE], 
tempname[MAXLINE] ; 

FILE  *in; 
import  $Node; 

main(argc,  argv) 
int  argc; 
char  **argv; 


char  *dbname; 
char  *getenv(); 

obj  $Node  theNode;  /*  local  object  variables  */ 
obj  $String  theOperator; 

if  (argc  >  1) 

I 

dbname  =  argv[lj; 

) 

else  if  (dbname  =  getenv("DBNAME  j) 


else 


printf("Must  specify  database  name,  either  as  a  command  line 
argument,  \nor  via  the  unix  environment  variable  command"); 
exit(l); 


AM_databaseOpen  (dbname,  0); 
in  =  fopen("ddb.in",  "r’j; 

fgets(tempname,  LINELENGTH,  in);  /*  read  in  the  node  name  */ 
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stmcpy(opname,  tempname,  (strlen(tempname)  -  1)); 
/•  assign  to  object  variable  */ 
theOperator  =  opname; 

/*  verify  node  exists  */ 

theNode  =  $Node$Lookup(theOperator); 

/*  delete  the  node  by  calling  the  delete  operation  */ 

$Node$Delete(theNode) ; 

fclose(in); 

) 

protect 

AM_databaseClose(dbname) ; 


Traverse  Tree 

/*  Program  Traverse  Tree  */ 

/*  This  program  is  used  to  traverse  the  entire  tree  &  */ 

/*  produce  the  PSDL  program.  */ 

/*  It  interfaces  with  the  User  Interface  through  ddb.in  */ 

/*  &  ddb.out.  */ 

/*  The  program  reads  in  the  required  information  in  ddb.in  */ 
/*  then  traverses  the  entire  tree  outputting  the  contents  */ 

/*  of  all  nodes  to  ddb.out  */ 

/*  The  required  information  in  ddb.in  is  */ 

/*  Root  Node  Name  */ 

/*  The  information  outputted  to  ddb.out  */ 

/*  for  each  Node  in  the  tree  */ 

/*  Node  Name  */ 

/*  Specification  */ 

/*  Implementation  (Optional)  */ 

/*  Control  constraints  (Optional)  */ 

#include  <stdio.h>  /*  include  standard  C  routines  */ 

#include  <string.h>  *  > 

#include  "string.def  /*  include  string  definitions  file  */ 

/*  local  variables  */ 

FILE  *in,  *out; 
char  rootnamelMAXLINE],. 
tempname  [MAXLINE] ; 

import  $Node; 

main(argc,  argv) 
int  argc; 
char  **argv; 
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char  *dbname; 
char  *getenv(); 

/*  local  object  variables  */ 
obj  $Node  theNode,  currentNode; 
obj  $Set(obj  $Node]  theNodes; 
obj  $String  theRoot; 

if  (argc  >  1) 

I 

dbname  =  argv[  1]; 

} 

else  if  (dbname  =  getenv(  "DBNAME")) 

I 

1 

else 

I 

printf("Must  specify  database  name,  either  as  a  command  line 
argument, \nor  via  the  Unix  environment  variable  DBNAMEXn'j; 
exit(l); 

} 


AM_databaseOpen(dbname,  0); 
in  =  fopen(  "ddb.in",  "r'j; 

/*  erase  the  contents  of  ddb.out  */ 
out  =  fopenf'ddb.out",  "w'j; 


fclose(out); 

fgets(tempname,  LINELENGTH,  in);  /*  read  in  root  node  name  */ 
stmcpy(rootname,  tempname,  (strlen(tempname)  -  1)); 

/*  assign  to  object  variable  */ 
theRoot  =  root  name; 

/*  verify  Node  exists  */ 
theNode  =  $Node$Lookup(theRoot) ; 

/*  output  root  node  contents  */ 

(void)  $Node$BuildDisplay(theNode); 

/•  Assign  children  of  root  to  variable  •/ 
theNodes  =  $Node$listSubnodes(theNode); 

/*  iterate  through  all  the  children  */ 
iterate(currentNode  =  theNodes) 


I 


/*  output  the  children  node  contents  */ 
(void)  $Node$BuildDisplay(currentNode) ; 
i 


) 


protect 

AM_databaseClose(dbname); 
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Makefile 


The  makefile  is  not  a  part  of  the  Design  Database  but  is  included 
to  assist  interested  parties  in  the  compilation  and  execution  of  the 
DDB.  Due  to  current  system  memory  requirements,  the  author  does 
not  anticipate  leaving  a  compiled  and  working  copy  of  the  DDB  at  the 
Naval  Postgraduate  School.  As  stated  in  Chapter  V,  each  application 
in  Vbase  requires  two  megabytes  of  memory.  This  fact  requires  that 
the  author  remove  applications  once  compiled  and  tested.  Therefore, 
the  uncompiled  programs  will  remain  on  the  "Suns2"  system.  The 
following  provides  the  steps  to  compile  and  execute  the  DDB. 

•  Obtain  a  fresh  copy  of  the  Vbase  Kernel  Database. 

•  Change  directories  to  the  "tdl"  directory. 

•  Type  "tdl  -v  *.tdl"  to  compile  the  tdl  definitions. 

•  Change  directories  to  the  "methods"  directory. 

•  Type  "make  application_program_name". 

Application_program_name  is  the  name  of  the  application  program 
to  compile,  i.e.  createRootNode.  This  command  will  compile  the 
COP  operations  code  as  well  as  the  application  program.  Type  this 
command  until  all  applications  programs  are  compiled. 

•  Type  "application  program  name"  to  invoke  the  application. 

The  make  file  for  the  Design  Database  is  as  follows. 


C  E  FLAGS  =  -g 

CLFLAGS  = 

CFLAGS  =  $(CEFLAGS)  $(CLFLAGS) 
.c.o:;  cop  -c  $(CFLAGS)  $*.c 


LIBRARY  =  -lvbase  -lm  -11 
SOURCES  =  Node.c 

OBJECTS  =  $(SOURCES:.c=.o) 
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traverseTree:  $(OBJECTS)  traverseTree . o 
cop  $(CFLAGS)  -o  traverseTree  \ 
$(OBJECTS)  traverseTree. o  -Ivbase  -lm  -11 

createRootNode:  $(OBJECTS)  createRootNode.o 
cop  $(CFLAGS)  -o  createRootNode  \ 
$(OBJECTS)  createRootNode.o  -Ivbase  -lm  -11 


createChildNode:  $(OBJECTS)  createChildNode.o 
cop  $(CFLAGS)  -o  createChildNode  \ 

$(OBJECTS)  createChildNode.o  -Ivbase  -lm  -11 

storeProperty:  $(OBJECTS)  storeProperty.o 
cop  $(CFLAGS)  -o  storeProperty  \ 

$(OBJECTS)  storeProperty.o  -Ivbase  -lm  -11 

getProperty:  $(OBJECTS)  getProperty.o 
cop  $(CFLAGS)  -o  getProperty  \ 

$(OBJECTS)  getProperty.o  -Ivbase  -lm  -11 

getParent:  $(OBJECTS)  getParent.o 
cop  $(CFLAGS)  -o  getParent  \ 

$(OBJECTS)  getParent.o  -Ivbase  -lm  -11 

getChildren:  $(OBJECTS)  getChildren.o 
cop  $(CFLAGS)  -o  getChildren  \ 

$(OBJECTS)  getChildren.o  -Ivbase  -lm  -11 

deleteNode:  $(OBJECTS)  deleteNode.o 
cop  $(CFLAGS)  -o  deleteNode  \ 

$(OBJECTS)  deleteNode.o  -Ivbase  -lm  -11 

CLEAN  : 

rm  -f  *.o  a.out  core  traverseTree  createRootNode \ 
createChildNode  storeProperty  getProperty  \ 
getParent  getChildren  deleteNode 
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